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1 Changes to this document 

Date Change Who 

12/20/02 Initial Creation Johnston McLamb Team 



2 Introduction 



2.1 Obje ctives 

R3 stands for Referrals, Reports, and Resources. 

The business objective of the R3 system is to provide an OPO a data entry and data tracking 
system to track ail referrals , potential donors and actual donors within their area of responsibility. 
There are currently three major areas to the system: 

Call Center: This portion of the system allows an operator to take basic referral information and enter 
in any data needed to facilitate a donation. This includes entering in screening criteria, basic 
hemodilution information, consent data, and medical/social information. 

Referral: This is the area where all of the clinical data for a referral/donor can be entered. This 
includes all the clinical information pertaining to an organ donor or a tissue donor. From here the 
recipient information can be entered/maintained, as well as the tracking information. 

Management: This area, allowable to only certain people, allows the user to maintain various system 
objects including security, users, organizations, hospitals, and lookups. 



2.2 Versioning l 

Version 1.0 of R3 was implemented into the production system on 10/1/2002. See section 17 for 
details on subsequent versions of the R3 system, and section 2 for information on how the versioning 
process takes place. 



2.3 History 



The R3 project replaces and enhances an existing product for LOPA, called OTIS. (Organ and Tissue 
Information System). This was a client/server system written in a proprietary language called 
"Delphi". In January of 2002, a proposal to rewrite and enhance this system using open Oracle 
technology was awarded, and work began in March of 2002 to begin requirements gathering and 
building the components needed to rearchitect the database and rewrite the system completely. 

The following diagram illustrates the original concept of what was to be included in Phase 1 of the 
system, as well as basic flow diagrams for the original system: 
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These diagrams were current as of 3/11/02. It was discovered later that certain screens that were 
critical to the operation of the system were not included in these diagrams, but were implemented 
anyway into the first version of the implemented system. These were the Cardiac and Pulmonary 
screens, and the registry deletion capability. 



12,4 This Do cu ment 

This document is intended to be an overview of the system, with specific sections dealing with 
process, validation, and knowledge of specific areas of the system. Also included is information on the 
technical architecture of the system, information which is necessary for the continued maintenance 
and enhancement of the R3 system. This is meant to be a living document. 
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3 Configuration Management/Development Process 

3.1 Project planning and ma na gement 

All life cycle tasks for the application, including definition of requirements, design, development 
and testing of the database and application code, and movement to production were defined and 
managed according to a detailed project plan prepared by Johnston McLamb and reviewed and 
accepted by LOPA. This plan was updated to reflect agreed on changes in scope, and the introduction 
of new tasks, individual task start or date changes, and completion of tasks. The project plan itself 
was developed using Microsoft's Project and was controlled by maintaining the project plan file in 
Microsoft's Visual Source Safe (VSS) product. Please see Appendix 1 for a copy of the original project 
plan. 



\3.2 Ap plication component configuration management 

All Oracle code components and core development documents are placed under a CMM Level 2 
configuration management approach, using VSS (Microsoft Visual Source Safe) as the source code 
repository. Individual Oracle PL/SQL components (functions, stored procedures, packages), 
embedded HTML, JavaScript and XML code, and standalone SQL scripts for conversions and 
application installation are developed and then managed through a standard check-in and check-out 
process controlled through VSS. 

Using VSS in support of this configuration management process ensured code changes were 
made in a controlled environment. Only managers and developers assigned to the R3 project are 
granted access to the VSS environment where the code was maintained. All code changes were 
logged by VSS, and VSS itseif controls the individual components, not allowing changes to be made by 
more than one person at a time. 

Once a given stored procedure or package has been completed in its initial form, all requests for 
changes (defects, enhancements or new functionality) are completed by checking out the relevant 
components from VSS, making the required changes, documenting the nature of the change in the 
affected code components (including an explicit reference to the original change request), and placing 
the version into the VSS repository. The version of the object in the VSS library also carried a "label" , 
which is marked by the developer with the Bugtrack identifier. 



3.3 A p plication component level documentation 

As requested by LOPA and as delivered by Johnston McLamb, all code components contain a 
description of the purpose and functionality embedded as comments. As noted above, whenever 
changes are made (to repair defects, expand or change functionality), additional comments are added 
to reflect the change(s), and to explicitly reference the change request giving rise to the change. 



3.4 Testin g 

The system development life cycle process followed for the design, development and testing, 
implementation and operations of R3 includes extensive testing at multiple levels. 

• Unit testing was conducted by individual developers on the project team, as individual work 
packages were completed. A work package corresponds to a single on-line screen, and includes 
the client-side processing, server-side processing and database updates associated with that 
screen. Unit testing was conducted by developers on each others' work. Unit testing was 
conducted according to an individual unit test plan developed for each work package. 
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These unit test plans were developed by the project team lead and the project manager, based on 
the screen layouts, functionality and individual field specifications. The unit test plans were then 
reviewed in detail by LOPA and revised as needed before turning them over to the developers for 
execution. A sample of these unit test plans is included as Appendix A. Developers checked off 
the individual conditions specified in the unit test plans as the basis for executing and completing 
the unit tests. Discrepancies were logged using BugTrack (described below) and were resolved 
before starting system testing. 

• System testing was conducted by individual developers on the project team, after unit testing 
was completed on the individual work packages. System testing was also conducted by the 
project team lead and project manager, by LOPA management and staff, and by external users 
engaged by LOPA. System testing involved testing multiple work packages together to perform a 
specified unit of work (e.g., setting up a new hospital, changing a user's security and access 
profile, taking a referral, recording an organ or tissue donation). System testing was also 
conducted according to a defined system test plan, specifying the individual units of work, 
business events and scenarios, variations and exceptions to be tested. The contents of the 
system test plan were developed by LOPA. Any discrepancies identified during system testing 
were resolved before beginning integration testing. The system test plan used by Johnston 
McLamb for the original development and implementation of the first release is attached as 
Appendix B. 

• Integration testing was carried out by the development team, after system testing was 
completed. Integration testing focused on testing the results of import external data files 
containing registered donor information from the Louisiana Office of Motor Vehicles (OMV), as well 
as registered donor information collected separately by LOPA. The integration test plan was 
developed by LOPA. Known integration testing discrepancies were resolved before beginning user 
acceptance testing. 

• User acceptance testing was conducted by LOPA and by external users under contract by LOPA, 
following successful completion of the integration test. The user acceptance test plan and content 
was developed by LOPA, and covered all aspects of the application, from the initial parameter and 
user set-up and management to taking referrals to organ and tissue recoveries to follow-ups with 
donors. In-scope discrepancies identified during this testing were resolved before the application 
was formally accepted by LOPA for migration to production operations. 

• Defect and enhancement testing is conducted by the development team on completion of 
assigned modifications to an individual stored procedure and its implementing package. As 
changes are evaluated after being logged, the affected stored procedures and packages are 
identified and checked out of the VSS repository by a developer. Once the changes have been 
completed, the modified component is checked back into VSS and compiled in the development 
environment. Individual changed stored procedures and packages are then unit tested individually 
to ensure the change being made accomplishes the intended result, and to make sure the 
unmodified portion of the component continue to function properly. 

• New release testing is carried out by the development team as part of migrating a new release 
of R3 into production. Individual change requests and the code changes they engender are 
organized into new releases according to priorities determined by LOPA management. Once a new 
release is defined, the individual stored procedures and packages comprising the new release are 
moved from the development environment into the test environment. The new release is then 
tested using a combination of individual unit testing and system testing, before being moved into 
production. 

Defect and enhancement tracking and resolution: 

Development issues, problems, questions, testing results and test discrepancies are logged 
using the Johnston McLamb BugTrack system. BugTrack is a web-enabled database application that 
captures bugs, issues, enhancements and database changes, assigns each to a developer, user or 
another project participant, allows updates to reflect work completed to fix the problem or resolve the 
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issue, automatically notifies recipients of origination and closure, and provides monitoring and tracking 
for open and closed bugs and issues. 

Only authorized individuals on the development team and LOPA management and staff (as 
well as other individuals under contract to LOPA) have access to the BugTrack system. The BugTrack 
application itself uses Oracle security and runs on a separate server outside the R3 development 
environment. 

All changes, whether defects, enhancements or new functionality, are logged in BugTrack. 
Typically, defects and change requests (enhancements and new functionality) are identified by LOPA 
management or by a member of the development team. BugTrack automatically generates an email 
to the recipient identified by the newly opened item's submitter. Once initially recorded, individual 
items are evaluated, clarification obtained where necessary, and then assigned to an individual 
developer. BugTrack provides a view of all items assigned to an individual, so an individual may log 
in, and see a list of items awaiting attention. 

When the developer has completed work on an individual item, the developer changes the 
item's status to from "open" to "completed" (and an email is automatically sent to the item's 
orginator). In the case of new modules, a new BugTrack item is opened to assign the completion of 
unit testing for the new component to a different developer. Once testing has been completed 
successfully, the individual BugTrack item's status is changed to "closed". When the item has been 
incorporated into a new release, the release date is recorded for that item. 

Periodic reviews of the status of open bugs and issues in BugTrack is included in informal daily 
team discussions and progress reviews, the weekly team meetings, and formal bi-weekly status 
reports provided to LOPA. 



3.5 Database change lo gging m 

Database changes may be made for several reasons: to correct conversion problems arising from 
data incorrectly converted over from the previous application (OTIS), to correct problems in the 
converted data introduced by the original application itself, or to change the user interface. 

• Conversion corrections are made by developing and testing individual scripts (collections of SQL 
or PL/SQL statements) in the development environment, re-testing them in the test environment, 
then executing these scripts in the production environment. The scripts themselves are managed 
using R3 configuration management procedures like any other code component. Specific details of 
changes made by executing scripts against the database are recorded in the individual BugTrack 
items identifying the need for the changes. Please see the conversion section for details on the 
conversion logic. 

• User Interface changes. Part of the R3 design includes storing some of the user interface (web 
page) characteristics in the form of database tables, so that changes in individual field labels, 
length, data type (number vs. text vs. date, and so on) can be made without having to modify any 
code). Some of the defects or other change requests require such changes to the user interface 
are implemented by making these database table changes in the development environment, then 
moving the revised database table contents to the test environment and re-testing, and finally 
moving the revised table to the production environment. 

In both cases, only authorized users defined to Oracle are permitted to make such changes directly. 



3,6 R3 Validation 
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R3 provides multiple forms of validation, ranging from the development process followed during 
its design, development, and testing, to the controls and system audit features designed into the 
system, to the documentation that accompanies the system. 

R3 was designed to meet the requirements of the Louisiana Organ Procurement Agency (LOPA), 
including additional requirements from the Food and Drug Administration (FDA), specifically Rule 11, 
as well as requirements implied by the Health Insurance Privacy and Portability Act (HIPAA). 
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4 Conversion 

4.1 introduc tion . J 

The previous system to R3 was called "OTIS". OTIS (Organ and Transplant Information System) 



4.2 Lo gic 



4.3 Data Model 

The following tables were needed for conversion: 



4.4 Code 
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5 Database/Datamodel 



5.1 Introduction 



\s. 2 Data model ] 

The following is the top level view of the R3 Data model. It is a large model, and split up into several 
pages. 



[5.3 Database Comments/ Data dictionary 

Please see Appendix 2 for a list of database column level descriptions and definitions. 



6 Environment/ Architecture 



6.1 Overall A rchitecture _____ _____ 

6.1.1 Security 

Security for R3 application will be provided in the following ways: 

SSL (Secure Sockets Layer) for client browsers for encryption of all infomation over the Internet 
User ids and passwords are stored at the database level, and encrypted using Oracle's internal 
encryption scheme. 

■ Application level security is maintained in several tables in the system. These tables and their 
security are accessible to the administrator of the system through the management console in the 
R3 application. Please see the security section of this document for more information. 

6.1.2 Web 

Web pages for presentment will be written in PL/SQL packages and stored in the database. 

• All users must have a JavaScript enabled browser Netscape or Internet Explorer. The following 
browser versions will be supported by the R3 application 

• Netscape 6 and higher 

• Internet Explorer 5.0 and higher 

• All font face, color, size, style, decorations, etc. shall reside in stylesheet classes. 

• All widths shall be specified in percentages where possible. This will allow for easier changes in 
screen width for the future. 

• All stylesheet information shall reside in one .CSS file. 

• All shared javascripts should reside in separate JS files when possible. 

• All font sizes to be specified in "px". 

6.1.3 Email __ 

The Online Billing application uses e-mail for the following purposes: 

• Sending error messages to administrator and tech support 

Sending information for UNOS interface to allow access by certain individuals for a period of time. 



6.1.4 Database 



• Oracle 9i Release 2 Enterprise Edition 
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6,1,5 PL/SQL Packages 



As of OLB 2.0, PDF conversion will be performed as part of the nightly import process that handles 
incoming bill printstreams and loads their data into the database. This conversion needs to occur after 
individual statements have been split out of a master printstream. This process will be called as part 
of the overall scripts that run to import the bills. 



6.2 Database 



6,2.1 Directory Structure 



The following are the required directories on the Database server: 



/r3 

/r3/import 
/r3/export 



Root 

Temporary files used during the OMV/Registry import processes. 
Fexport files (currently not used) 



6.3 Web Architecture 



6,3,1 Directory Structure 



The directory structure below resides on the webserver and holds all the static contents used by the 
application. 



/r3???? 



htm 



htm/images 

htm/images/bullets 

htm/images/buttons 

htm/images/calendar 

htm/images/logos 

htm/images/menu 

htm/images/misc 



Root directory. ???? is replaced with the system being used such as 
r3lopa, r3mora, r3dev, etc.) 

Document root for the server. Only used so that the index.htm forwards 
the user directly to the /pls/r3???? PL/SQL dad entry in Oracle. 

Image root 

bullet images 

button images 

images for calendar fields 

logos for the OPO 

images used by menu system 

miscellaneous images (bars, clear pixels, etc.) 



htm/include javascript and ess files 

htm/include/tigracalendar code and files for the tigracalendar popups 
htm/include/tmapcube code and images for the rotating cube applet 
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6.3.2 Cascading Style Sheets 

Cascading style sheets will be used to control all text related items for fonts faces, colors, sizes, and 
backgrounds. No font commands shall be used directly in any generated HTML code from the 
application. All such items will be controlled by style classes using div, span, and id's. 

htm/include/r3.css This is the main stylesheet file for all R3 pages. Standard style classes, 

text controls, fonts, and backgrounds with correct RGB values are 
contained here. 



6.3.3 Javascript 

Javascript will be used as necessary for such items as top navigation dynamic HTML and real time 
input validation on forms. All files come from the htm/include directory: 



bloodvol.js 


Blood volume calculations and edits 


calendar.js 


Javascript used for calendar popups 


Formchek.js 


basic validation routines for forms 


formValidations.js 


formvalidation routines and specific corss field edits for certain screens 


layers.js 


functions for handling layers 


menu_array.js 


menu arrays for the menu system 


mmenu.js 


menu functions for the menu system 


ruleouts.js 


special edit checks for ruleouts 



6.3.4 Crystal Reports Interface 

Several links on the R3 application connect to a Crystal Enterprise server for reporting. Please see the 
document on crystal enterprise for further details. 



6.3.5 Menu System 



The menu system is a 3 rd party product from Milonic DHTML Website Navigation Menu Version 3.3.19. 
Written by Andy Woolley Copyright 2002 (c) Milonic Solutions Ltd. All Rights Reserved. If further 
information is needed, please vist http://www.milonic.co.uk/menu or e-mail menu3@milonic.com . A 
site license was purchased in June of 2002. 



6,3.6 Rotating Cube 



The TmapCube applet is a product of Anfy Team. More information can be obtained at 
http://www.anfyteam.com. 
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7 Import/Export Functionality 



7.1 Overview . _____ 

The R3 system currently has two tables which are fed from external sources: OMV (Office of Motor 
Vehicles) and the Registry. These are currently only on use for the LOPA project. The Import 
functionality in this application allows the user to load these 2 files manually on an as needed basis. 

The files are in CSV (Comma Separated Value) format and contain a specific field format for each 
corresponding feed. The current code is set to match these 2 specific formats. 



7.2 Process Flow 



R3 Import Process 

• TATU3M 



O - Countlnfl 




\f73 Architecture 



Using the R3 web interface, users can upload these CSV files using the management console. 
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7,3,1 Oracle Document Gateway 



The oracle document gateway is used in the application here to allow the uploading of the CSV import 
files through a web page. File uploads are automatically stored in a table web_documents_t by the 
P17SQL web gateway. This data is stored as a BLOB to be later handled by the application. 



7.3.2 9i External Tables 



To allow the reading of the CSV files after they have been uploaded to the database and written to the 
file system, the use of Oracle 9i external tables is utilized. This allows SQL operations to be performed 
on the CSV files which are linked to tables. 

This use of external tables also allowed us to avoid the use of calling external sqlload commands which 
would have been necessary in the prior Oracle 8i release. 



7.3.3 Tables 



As shown in the process flowchart in the Overview section, several database tables are utilized to 
support the import process from start to finish. Below is a list of the tables involved and there use. 



Table 


Description 


web_documents_t 


This table is used by the Oracle Web Gateway to store file uploads. The CSV 
file uploaded by the user is stored here in BLOB format. 


import_flat_ext_t 


External table with one large varchar2 column. Used to do a record count on 
the import. csv file in the system. 


Import_export_t 


This table actually stores the CSV files uploaded, the current status of the 
existing import, and all related log files and record counts from the import 
process. 


registry_ext_t 


External table attached to the import.csv file. The columns are matched to 
the registry CSV layout. 


registry_deleted_t 


A record of all deleted registry records. Data is moved here from the registry 
tables when a user deletes a registry record from the Web. 


registry_t 


The actual registry table after import. 






omv_ext_t 


External table attached to the import.csv file. The columns are matched to 
the OMV CSV layout. 


omv_deleted_t 


A record of all deleted OMV records. Data is moved here from the OMV tables 
when a user deletes an OMV record from the Web. 


omv_t 


The actual OMV table after import. 


omv_reg_snapshot_t 


A union of the registry and OMV data after it has been imported. This table is 
rebuilt after an import is performed. 
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7.4 Process „___ ] 

The process of importing CSV data from the web and converting into Oracle tables contains several 
steps outlined below. Although there are several steps below, these are actually processes mostly in 
the backend system. The user only sees 2 major steps from the Web interface: 

The Upload process which includes Upload, Count, and Validate 

The Import process which includes Import, Duplicate Processing and Snapshot Update. 

The process is presented this way to the user so that they can decide after Count and Validation if 
they want to proceed with the import. If they decide not to proceed, they can delete the file just 
uploaded before the import process, thus leaving the current OMV and Registry data in the system 
unchanged. 

Note: Only one import process is allowed to be run at one time. The user cannot import a file from 
the management console if an import process is currently running in any stage other than 
Completed. 



7,4,1 Upload 

Here the user is actually uploading the CSV file to the Oracle database. Using standard HTML file 
upload, the user selects the CSV file and type from their local machine and send the data to the oracle 
server. 

The Oracle gateway automatically places this uploaded file into the web_documents_t table in a BLOB 
format. From there, this data is moved to the import_export_t table and an import process started. 

The file just uploaded is then copied to the database file system as r3\import\import.csv. This is the 
directory and filename which is used by all the external tables defined for the import process. The 
external tables link to this file for use in the next steps. 



7.4.2 Count 



A simple select count(*) from import_flat_ext_t table is performed. This table contains one large 
varchar2(4000) so it can basically count the number of records in the import.csv file. 



7.4.3 Validate 



Depending on the type of file that was uploaded and saved to the import.csv file, either the omv_ext__t 
or registry_ext_t table is selected from. Although a select count(*) is performed, a basic format 
validation is also performed since the format of the external table has all the matching columns in the 
import.csv file which it is reading. 

The process of doing a select from these external tables also will cause an import.log and import. bad 
file to be generated. These 2 files are then taken and attached to the import_Export_t record 
currently being used. This will allow the user to view these files from the management console to see 
what records have failed the validation and decide if they wish to proceed with the import process. 
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7,4,4 Import 

The import step is slightly different depending on the type of file being imported. The specific are 
below: 

Registry (KEY FIELD = read) 

The registry data is imported to the registry_t table and always appended. Data from the 
registry_ext_t external table is inserted into the existing registry_t table. Since data is received 
incrementally, the existing data should never be overwritten. 

To ensure that updates in R3 take precedence the insert will exclude both items marked as 
deleted in R3 and items that already exist in the registryj: table so that they will not be 
overwritten. This means that once a registry record (key = recid) is brought into R3, it can never 
be updated through the import process. It must be changed via the web interface. 

OMV (KEY FIELD = license) 

The OMV data is imported into the omv_t table and overwritten. Since OMV files are always full 
extracts, the omvj table is deleted and replaced by the data from the import. 

Since users can mark OMV records deleted in R3, the import process will skip records that exist in 
the omv_deleted_t table when performing this process. 



7.4,5 Duplicate Processing 



The next step is to remove duplicates from both the registry and omv tables after an import has been 
done. This must be done before the merging of data in the last steps. Since these edits cross both 
tables, it always performed no matter which file was imported. The registry data takes precedence 
over OMV data in most cases which is evidenced by the processes below. The duplicate processes 
performed are: 



• Remove OMV SSN's that are in the registry 

• Remove OMV License numbers that are in the registry 

• Remove Last Name, First Name, Date of Birth OMV records that are in the registry 

• Delete duplicate license numbers in the OMV and keep the most recent updated 

• Delete duplicate SSN numbers in the OMV and keep the most recent updated 



7,4.6 Update Snapshot 



In this last step, a UNION ALL is performed which combines the omv_t and registry_t into a table 
called omv_reg_snapshot_t. This is the table which is used for processing in the R3 application for 
queries and updates. 

The SQL for the creation of this table also performs some validating and reformatting using SQL 
functions to ensure that the data combined from these 2 tables results in the same format for 
common columns such as name, phone, city, state, etc. 
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8 Installation of System 



8.1 Introduction 

8.2 Server Validation 



8.3 Ap plication Setu p 



8.4 Application Validation 



9 Lookup Tables 



9 .1 Overvie w 

Lookup Tables are used in R3 primarily to populate drop-down select lists. The tables define the 
option values and descriptions for a select list. 

Lookup Tables are defined by two database tables: LOOKUP_TABLES_T and 
LOOKUP_VALUES_T. Multiple logical Lookup Tables are defined in LOOKUP_TABLES_T. 
LOOKUP_TABLES_T defines the name of the Lookup Table and its description. 

LOOKUP__VALUES_T will have one-to-many entries for each table defined by 
LOOKUP_TABLES_T. Each entry contains the option value (LK_VAL_ID) and description 
(LK_VALl_DESCRIPTION). In LOOKUP_VALUES_T, all occurrences of LK_VAL_ID are unique. 
LK_VAL_ID is usually used to populate database columns that correspond to the Lookup Table. 



9.2 Table Description 

Lookup Tables are used by WEB_FIELD_EDITS_T to create database-driven select lists. To 
create a database-driven select list, WEB_FIELD_EDITS_T should be populated as follows: 



Column 


Value 


LK_TABLE 


LOOKUP_VALUES_T 


LK__VALUE 


LK_VAL_ID 


LK__DESCRIPTION 


LK_VALl_DESCRIPTION 


LK_FILTER 


LK_FILTER will be used to populate the WHERE 
clause that the application builds to select records 
from LOOKUP_VALUES_T. Typically, LK_FILTER 
should specify only active records from a given 
logical Lookup Table, as shown in the example for 
Suffix taken from W E B__FI E LD_E DITS_T below: 
lk_name= , LK_SUFFIX , and lk_status='A t 

Also, in R3, there is a requirement to display in 
select lists inactive Lookup Table entries that 
have been previously selected and stored in the 
database. The example below modifies the first 
example to satisfy this requirement: 

Ik name= , LK SUFFIX' and (lkj>tatus='A' or 
lk_valjd = #lk_suffix#) 


LK__SORT 


LK_SORT 


In some cases, R3 pages must perform processing based on specific select list items. When this is so, 
the pages look for items matching a given description. It is therefore critically important that the 
lookup descriptions entered by the user match what is expected by the R3 application for these 
specific select items. Below is a list of Lookup Tables for which certain R3 pages look for specific 
descriptions: 


Lookup Table Name 


Lookup Description Value 


Age Unit 


Year 


Agency (LOPA) 


LOPA 
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Lookup Table Name 


Lookup Description Value 


Agency (MORA) 


MORA 


Body Part 


Heart 


Body Part 


Intestine 


Body Part 


Kidney Left (or Left Kidney) 


Body Part 


Kidney Right (or Right Kidney) 


Body Part 


Liver Split 1 (or Split 1 Liver) 


Body Part 


Liver Split 2 (or Split 2 Liver) 


Body Part 


Liver Whole (or Whole Liver) 


Body Part 


Lung Left (or Left Lung) 


Body Part 


Lung Right (or Right Lung) 


Body Part 


Pancreas 


Culture Result 


Growth 


Death Type 


Asystole 


Eye Outcome 


Eye Referral 


Eye Ruleout 


Ruled Out 


Eye Ruleout 


Medical History 


Observation Type 


CBC 


Observation Type 


Lab 


Observation Type 


Urinalysis 


OPO Type 


Entry 


Organ Disposition 


Not Recovered 


Organ Disposition 


Transplanted 


Organ Outcome 


Organ Referral 


Role 


Hospital Staff 


Role 


Organ Referral Coordinator 


Role 


Referral Contact 


Role 


Tissue Referral Coordinator 


State (LOPA) 


Louisiana 


State (MORA) 


Mississippi 


Tissue Age Ruleout 


Female 


Tissue Age Ruleout 


Male 


Tissue Outcome 


Ruled Out 


Tissue Outcome 


Tissue Referral 


Tissue Ruleout 


Age 


Tissue Ruleout 


Medical History 


Title 


CEO 
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Lookup Table Name 


Lookup Description Value 


Title 


President 



Other attributes may be optionally defined for each LOOKUP_VALUES_T entry. These 
attributes will not appear in the select list, but may be used as additional filtering criteria. To define 
additional attributes for a Lookup Table, a value must be entered for LK_VAL2_NAME and/or 
LK_VAL3_NAME in LOOKUP_TABLES_T. Then, WEB_FIELD_EDITS_T entries must be created that 
correspond to LK_VAL2_NAME and LK_VAL3_NAME, where TABLEJWIE equals the name of the 
Lookup Table as defined in LK_NAME of LOOKUP_TABLES_T, and FIELD_NAME equals the value 
defined in LK_VAL2_NAME or LK_VAL3_NAME of LOOKUP_TABLES_T. These WEB_FIELD_EDITS_T 
entries will usually define preloaded drop-down select lists (see below) that the user will be prompted 
to choose from when maintaining Lookup Tables using the Management Console. 

Lookup Tables may be defined as preloaded tables, in which case they are not defined in either 
LOOKUP_TABLES_T or LOOKUP_VALUES_T. They are completely defined by their 
WEB_FIELD_EDITS_T entry. As such, they are not modifiable by a Management Console user. 
Typically, preloaded tables should be used only when they meet all of the following criteria: 

• number of entries is small (for example, 5 or fewer) 

• values and descriptions are not subject to change 

• Management Console users do not require access for maintenance purposes 

Preloaded tables are defined by the PRELOAD_VAL and PRELOAD_DESC columns in 
WEB_FIELD_EDITS_T. PRELOAD_VAL should contain a comma-delimited list of items that will be used 
for the option values in the drop-down select list. PRELOAD_DESC should contain a comma-delimited 
list of descriptions that will correspond to each PRELOAD_VAL item. 

Please note that the LK* columns and PRELOAD* columns on W E B_FI E LD_E DITS_T are mutually 
exclusive. If values for PRELOAD* columns are specified, then the Lookup Table will be treated as a 
preloaded table and any values specified for the LK* columns will be ignored. 
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10 Management Console Areas 



1 0.1 OPOs / Organizations 



This set of screens manages the OPO entities and Organizations in the R3 system. 



10.1.1 OPO List 



10.1.1.1 Overview 



5 LOPA - Louisiana Gigan Pioeuiemenl Agency - RRR - Microsoft Interne! Hnploier 



Home Cell Center 9 Search * Management v Tools * 



Referrals Reportsend Resources 



OPO List 









Rows 1-10 of 15 




I 


MtXT > || tAST » 


I Action 


I Code 1 Name 


I Type 


| Address 1 


| Crty ! State 


I Zip 


| Fax 


j Comments | 


(EM 


X ABCD 


lEntry 


123 


CITY 'Alabama 


1111111 


„(U1)±U:t1JJ 




ream 


IBBUE 00 


Entry 










[Edit] 


KB KB OPO 


lEnlry 


X 


X [Louisiana 


[111111 


(111)111-1111 


. , . 

j 


fEdin 


KLB KEVIN'S NEW OPO 


Entry 


X 


X Louisiana 


11111 


(111)111-1111 




fEdlfl " 


AAAAA LOPA 


jEntry 


X 


j ]Xiaska 


1(11111 


((111)111-1111 


■ ■ I 


(Edin 


222 OPO 1 ENTRY 


Entry 


ADDRESS 1 


CITY Alaska 


20175 


(111)222-3333 


COMMENTS 


[Edit) 


X OPO 2 REPORT TO 


{Report to 


ADDRESS 1 


CITY" Alaska 


T201 75-9 988 


(277) 888-3546 


COMMENTSX ..] 


flsdifl" 


ODD X 


Entry 


32342 


432342342 Alaska 


11111 


(111)111-1111 
(111)111-1111 


COMMENTS 


X X 


lEntry 


X 


X iCouisiaria 


Iiii rr 


Edit! 


XX X 


Entry 


X 


X Louisiana 


11111 


(111)111-1111 






10.1.1.2 Processing 

This screen present the user with a list of all OPO records in the system. This list is displayed 10 
records per page. 

10.1.1.3 Database Tables Updated 

None 

10.1.1.4Special Edits 

None 
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10.1.1.5 Actions 

Edit Edit the corresponding OPO record in a new window. 

Add New OPO This button will open a new window to add a new OPO record 

First Display first page 

Previous Display previous page 

Next Display next page 

Last Display last page 



10.1.2 View / Edit / Add OPO 



10.1.2.1 Overview 



^3 LOPA - Louisiana Oi gan Procuiement Agency - RRR - Miciosoft Internet Explore* 



OPO Information 



OPO ID: 
Code: 
Name 
OPO Type: 

Comments 



Organizations 



Address Line 1: [ address 




Address Line 2: |apdress 2 
City 
State: 
ZIP 



jCTTY 



I Alaska 



I 



[20175 



Fax Number {(111)222-3333" 
Active? |g 



Save & Close 



~| [Close | 



I Action 


1 Organization I 


lEdttl 


LOPA 


fEdltl 


SOUTHERN EYE BANK 


[EOT 


XXX 


fEdltl 


XXXA 


fEdltl 


AASAS \ 



Add Organization 



10.1.2.2 Processing 

This screen allows a user to Add, Edit, and View OPO Information. Along with the OPO information, 
the organizations that are assign to the OPO is also displayed. This screen uses the user security to 
determine if a user has Add/Edit/View capabilites. 

The organization listing on the right has space indenting to show the hierarchy present within 
organizations. 

10.1.2.3 Database Tables Updated 

Opo_t 

Organization^ 
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10.1.2.4 Special Edits 

If this is an Add function, the organization window on the right is hidden until the new OPO has been 
saved to the database. 



10.1.2.5 Actions 

Save & Close 

Close 

Edit 



Save data and close the popup window 
Close window and cancel any changes 
Edit/View organization 



10,1.3 View / Edit / Add Organization 



10.1.3.1 Overview 



-3 LOPA - Louisiana Organ Procurement Agency - RRR - Microsoft Internet Explorer 



Organization Information 



Organization ID: 

OPO: 

Name 

Parent Organization 

Comments 

Address Line 1: 

Address Line 2: 

City 

State 

Zip 

Fax Number 

Restricted Access to 
Hospitals for this EyebaiiK: 

Active? 



108 

OPO 1 ENTRY 



(SOUTHERN EYEBANK 



ACCESS ONLY TO El 
REFERRALS IN gtf 



|asoap 



[SAOSOSA 



| Louisiana"" 



him 



tCiii)in-iiinr 



| SEB~SOUTHERN EYE BANK 



Save & Dose 



Gose 



Organization Contact 



Action I Last 



Title Phone 



Edit! FSDSFDSFDFDPresident<111) 
JPeletej „ ; Sl1M1tl 



Add Contact 



10.1.3.2 Processing 

This screen allows a user to Add, Edit, and View organization information. Along with the organization 
information, the contacts that are assigned to the organization is also displayed. This screen uses the 
user security to determine if a user has Add/Edit/View capabilites. 

10.1.3.3 Database Tales Updated 

Organization^ 
Organization_contact_t 

10.1.3.4 Special Edits 

If this is an Add function, the contact window on the right is hidden until the new organization has 
been saved to the database. 
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10.1.3.5 Actions 

Save & Close Save data and close the popup window 

Close Close window and cancel any changes 

Add Contact Add a new organization contact 

Edit Edit/View a contact 

Delete Delete a contact 



10,1,4 View / Edit / Add Organization Contact 



10.1.4.1 Overview 



V*| LOPA - Louisiana Organ Procurement Agency - RRR - Microsoft Internet Eh. 



MM 



Contact Information 



Contact ID: 696 



Prefix: 
Title: 

First Name: 
Middle Name: 
Last Name: 
Suffix: 

Address Line 1: 

Address Line 2: 

City: 

State: 

Zip Code: 

Phone: 

Email Address: 
UNOS Contact: 



ESSS5H. 



ISFOFP 



|fspsfp 



1 



SFDFDS 



SFOSFD 



Louisiana 



011)111-1111 




10.1.4.2 Processing 

Add/View/Edit contact information. Since several data elements in the R3 database have contact 
information (hospitals, eyebanks, etc.), this is the same screen that is used across the application. 

10.1.4.3 Database Tables Updated 

Organization_contact_t 
Contact t 



10.1.4.4 Special Edits 

None 
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10.1.4.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 



10.2 Security Profiles 



10.2,1 List Security Profiles 



10.2.1.1 Overview 



3 LDPA - Louisiana Oiyan Pioeuiemenl Agency - RRR - Miciosofl Internet Explore! 



Home Call Center ^ Search " Management ^ Tools 



Referrals Reportsand Resources 



Security Profiles 



Rows 1-11 of 11 



[Actio nj Name 


| OPO Name 


[ Comments | 


Edit! ADMIN 


0P01 
ENTRY 


ADMIN SYSTEM PROFILE 


lEditlieAlltME^ER^EMMM 








Editi CALL CENTER - WRITE 


OP01 
ENTRY 




fEdifl DELETE FOR FILE 
ATTACHMENTS 


LOPA 




[Edit] EYE8ANK 


OPO 1 


EYE BANK READ ONLY PROFILE. USED IN CONJUNCTION WITH THE RESTRICTED ' 


fidTfl MAN AG E ME NT - R EAD 6 N LY 


ENTRY 
OPO 1 
ENTRY 


EYEBANK FIELD ON THE ORGANIZATION TABLE 


Edit! OMV REGISTRY SEARCH AND LOPA 
UPDATE 


OMV REGISTRY SEARCH AND UPDATE 


Edit) REFERRAL- READ ONLY 


0P01 
ENTRY 




SfJi REFERRAL -WRITE 


0P01 
ENTRY 


i 


lEfljfl SECTEST 


0P01 
ENTRY 


PROFILE FOR TESTING SECURITY ALONO WITH THE SECTEST USER ID 


Edltl UN0S 


0P01 
ENTRY 


' " " " " ' " " i 




10.2.1.2 

10.2.1.3 Processing 

List all security profiles in the R3 system. This screen allows the users to Edit or Add security profiles. 
Security profiles in the R3 application define what accesses are allowed to every Window/Screen in the 
R3 application. These security profiles can later be assigned to users who access the R3 system. 

10.2.1.4 Database Tales Updated 

None 



10.2.1.5 Special Edits 

None 
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10.2. 1.6 Actions 

Edit 

Add New Profile 



Edit security profile 

Add a new security profile 



10,2.2 View / Edit / Add Security Profile 



10.2.2.1 Overview 



'3jL0PA - Louisiana Organ Piocuiement Agency - RRR - Microsoft Internet Exploit 



Security Profile 



Profile ID: 42 

Name: [call center « read only | 



Comments: 



OPO: 10P01 ENTRY 



| Save & dose | Close | 



Window Security 



Security 



Comments 




Add 
Update 
FuB 



Read IE 



Read 



Read IS 



{none} jg 

^ 1 



FuO 



{none) jg 



(none) IE 



Call Center - Consent Data 



Call Center - Enter New Referral 
Call Center - Main Entry 



Call Center - Med / Social History 



Call Center - Ruieout Reason 
Call Center- Screening 
Donor 



Main 



Home, help, privacy, warning 



Management - Audit Data 



Management - Consent Addendum 



J 



{none) IS] Management- Eyebanks 



10.2.2.2 Processing 

This screen is used to modify a security profile. Security profiles are driven by Windows in the R3 
application. Every web page in the R3 application belongs to a Window element. Every window has a 
defined access which can be controlled from this screen. The accesses are: 

{none} No access at all 

Read Read only access. Data can not be changed 

AddAdd only access 

Update Update and Add access 

Full Add, Update, and Delete access 

10.2.2.3 Database Tales Updated 



10.2.2.4 Special Edits 

None 
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10.2.2.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 



10.3 Users 



10.3.1 User Search Form 



10.3.1.1 Overview 



LOPA - Louisiana Oigan Piocwement Agency - RRR * Miciosofl Internet Explore* 



Home Cull Center ▼ Search w Management^ Toots 



Referrals Reports end Resources 



Instructions 



mm 



Find User 



Search Filters 






SSN: 


! 


User Name: 


1 


Employee Status: 


CM 


Last Name: 


1 


First Name: 


1 


Employee Number 


I 


Manager 


el 


Organization: 


§1 



Enter search criteria to search for employees in the system. 
Select your sort order and records per page below. 
Hit Query to see the results. 



Sort Results By) Last Name Igj | Ascending 
Records per page jio^f 



m 



10.3.1.2 Processing 

This form is used to search for users in the R3 application. The search filters available are presented 
on the left side of the screen. Instructions and result options are displayed on the right. This form 
allows the user to specify how they want the results sorted, and also how many records of the result 
should be displayed per page. 

10.3.1.3 Database Tales Updated 

None 

10.3. 1.4 Special Edits 

None 



10.3.1.5 Actions 

Query 



Run the query 
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10.3.2 User Search Results 



10.3.2.1 Overview 



3 10 PA - Louisiana Uigan Piocurcment Ayency - RRR • Microsoft Internet Exuloier 



Home Call Center " Search * Management " 



Referrals Reports end Resources 



I? 



User Search Results 



<KJ FIRST | 


| < PREVIOUS | 


R0W811 - 


20 of 305 




| NEXT f> H tAST f» 


1 Action 


1 User Name 


j Last Name 


I First Name 


! Hire 


l Termination I 


fEditl 
fEditl 


LBATSON 
ABAUDOIN 


BATSON 
BAUDOIN 


LESLIE 
ASHLEY 


[10708/2000 
06711/2001 




[Edit! 


SBAUDOIN 


BAUDOIN 


STEVEN 


'05/11/2001 




fEditl 


TBEAVERS 


BEAVERS 


TINA 


07/20/2000 


10728/1994 


Edit! 
fEditl 


A8ECKER 
S8EENE 


BECKER 
8EENE 


'Anfta 

SANDRA 


[02/17/1997 
08/3071995 


12*31/1997 ) 
12/31/1996 




PBENNETT 


BENNETT-CHARLES 


PATRICIA 


102/1671998 


'02/28/1999 I 


fEditl 


JBERNARD 


BERNARD 


JOANIE 


08/08/1988 


12/31/1999 


fEdffl 


W81AS 


BIAS 


iWADE 


;ji&no7i200i_ 




fEditl 


CBOBO 


BOBO 


CATHY 


06/14/1 999 




Add New Employee ) 








| New Search | 



10.3.2.2 Processing 

Displays search results from the user query screen. Results are displayed in a paging format for 
speed and viewing. The default is to display 10 rows at a time, however this can be changed on the 
search form. 



10.3.2.3 Database Tales Updated 

None 



10.3.2.4 Special Edits 

None 



10.3.2.5 Actions 

Edit Edit the corresponding employee record in a new window. 

Add New Employee This button will open a new window to add a new employee record 

New Search Display the user search screen 

First Display first page 

Previous Display previous page 

Next Display next page 

Last Display last page 
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10.3.3 View / Edit / Add User 



10.3.3.1 Overview 



•3 LQPA - Louisiana Organ Procurement Agency - RRR - Miciosolt Internet Explorer 



Main Info 


User 1(1:1379 


Employee Number]! 


| 0 Check If Active 


0 Organ Staff 


□Tissue Staff 



Prefbc 

CM 



First Maine 

[LESLIE 



Middle Name 

E 



Lost Name 

feATSON 



SUlTtX 



initials 



Employee Information 



Trainee 



Employee Type 
Employee Status 

Buildin g 201 9 
Title 



Comments 



Hire P^^ h 0^2000 | T°] 
Term Datej E l 



Organization ! lopa 



RECOVERY COORDINATOR 



Manage rjRANUM, KELLY 

OfTJce l g| 
OMsionl jj 



5 



Address Information I 


[ Personal Inf ormation 






Address Line 1:| S 


8SN LZ ZJ 


Address Line l\ \ 


Driver License #f~~ | 


CityP IstatelAlaslco SlZipl I 


TaxStatUS|S^ngle gj 

Birth Datej E3 


BusPhonef^ ^] Home Phone|5048339S80 | Fax PhoneQ j 


Cell Phone[SQ44322488 CarrierJ gj Exp.Datef |£3 


Gender: O Male © Female 


Beeper Local|s04572i 490 | Regional) j Type| Alphanumeric gj 





Miscellaneous Information 



System / Security 



Visa Num£ 

AAAp 
NumberL 
Parkfng 
Card Num 1 - 



AT&T 

Phonecard fBS6i7535i76070 

Num 



AAAExpr- 
DateL. 



Fuelmar 
Nui 



anr 

tmL 



Parking Lot|A |g| 



User Name^jBATSON 
Password! 



Confirm[[ 



Sync With 



Crystal: 1 
Email^BATSON@LOPA.0RG 



Profiles 



ADMIN 

CALL CBITER - READ OMY 

CALL CENTER - WRITE 

DELETE FOR RLE ATTACHMENTS 



REFERRAL - WflTE 



Save & Close 1 1 Close | 



EU 1 



10.3.3.2 Processing 

Used for editing individual employee records. 

10.3.3.3 Database Tales Updated 

Employee_t 
User_profile_t 

10.3.3.4 Special Edits 

Check if Active This field is used to activate or deactivate a user in the R3 application. When 
a user is deactivated, his Oracle user ID is turned off in the database. This will prevent 
access to the system at the database level. 
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User name The R3 application uses Oracle database access for login purposes. The user 
name field specifies the actual useMd to be created in the oracle database. When a user 
is added, this user id is actually created in the oracle database along with the password 
entered. 

Sync Crystal The R3 application has several links which run reports from the R3 application. 
To allow users of the R3 application to also login to the Crystal Enterprise, an interface is 
in place which keeps R3 and Crystal users and passwords synchronized. By checking this 
box, user and password information is sent to the Crystal database to ensure that these 
items are in sync. 

Profiles This selection window allows the administrator to assign security profiles to a user. 
Remember that this controls what access the user has to what screens in the application. 

10.3.3.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 



10.4 Hospitals 



10,4.1 Hospital Search Form 



10.4.1.1 Overview 



'3 LOPA - Louisiana Organ Piocurement Agency - RRR - Microsoft Internet Exploier 



ife m W®> Safe 

Home Cell Center w Search w Management v Tools 



Referrals Reportsend Resources 



m 



Hospital Search 



Search Fillers 


Code: 


i 1 


Name: 


1 


Hospital Type: 


m 


Region: 


m 


City: 


1 


State: 


n 


Phone: 


! 


Transplant Center: □ 



Instructions 


» Enter search criteria t 

* Select your sort order 

* Hit Query to see then 

Sort Results By: 
Records per page: 


o search for hospitals In the system, 
and records per page below, 
asults. 


HosptalD f£j (Ascending £j 

10E| 

ggy] 



t: mm mmes^, A 



10.4.1.2 Processing 

This form is used to search for hospitals in the R3 application. The search filters available are 
presented on the left side of the screen. Instructions and result options are displayed on the right. 
This form allows the user to specify how they want the results sorted, and also how many records of 
the result should be displayed per page. 



10.4.1.3 Database Tales Updated 

None 

10.4. 1.4 Special Edits 

None 
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10.4. 1.5 Actions 

Action 1 



Description 



10,4.2 Hospital Search Results 



10.4.2.1 Overview 



Referrals Reportsand Resources 



LOPA - Louisiana Organ Procurement Agency - RRR - Microsoft Internet l~3Cplorei 

Home Cull Center w Search w Management ~ Tools 




Hospital Search Results 



« FIRST |[ <} PREVIOUS | 




ROWS 11 -20 0f657 






I KEXT> j| 


LAST » 


i Action j Code j Hospital Name 


(Active 




ti\ City 


| State | 


Phone 


{ Region 


Ouhb! Trans. Ctr.l 


(Edit) ARSJ ST JOSEPH REG MED CTR 


IN 






'Arkansas 




Unknown 


N 


j 


fEdin ARUA UNIV. HOSPrTAL OF ARKANSAS 


Y 


04001 6~ 


LITTLE ROCK 


Arkansas 




Unknown 


Y 




[Edit] AZGS J300D SAMARITAN REG MED CTR 
fEdin AZHH HEALTHWEST REGIONAL MED CTR 
I£dJ AZSJ jST. JOSEPHS HOSPITAL 


if 

Y 

Y 


030002 
030008 
030024 


PHOENIX 
PHOENIX 
PHOENIX 


^Arizona 
Arizona 
Arizona 




Unknown 
Unknown 
'Unknown 


Y 
Y 
" N 


i 


fEdftl AZTV VA MEDICAL CENTER - TUCSON 


Y 


0301 3F 


TUCSON 


Arizona 




Unknown 


N 




fEditl AZUA lpNIV. OF ARIZONA MED CTR 


Ml. 


030064 


TUSCON 


{Arizona 




Unknown 


Y 


J 


fEdlti BUN ANOTHER LA HOSP. 
fEditl ?CA8E 1ST. 8ERNADINE MED CTR 


Y 

Jr 


050129 


LACI7Y 

SAN BERNADINO 


Louisiana (111)111-1111 

[California 


Unknown 
Unknown 


N 

Y 


s 


fEditl CABHALTA BATES MED CTR 


Y 


050305 


BERKLEY 


California 




Unknown 


Y 




Add New Hospital | 














| New Search 



m 



10.4.2.2 Processing 

Displays search results from the hospital query screen. Results are displayed in a paging format for 
speed and viewing. The default is to display 10 rows at a time, however this can be changed on the 
search form. 

10.4.2.3 Database Tales Updated 

None 



10.4.2.4 Special Edits 

None 
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10.4.2.5 Actions 

Edit Edit the corresponding hospital record in a new window. 

Add New Hospital This button will open a new window to add a new hospital record 

New Search Display the hospital search screen 

First Display first page 

Previous Display previous page 

Next Display next page 

Last Display last page 



10.4.3 View / Edit / Add Hospital 



10.4.3.1 Overview 



<5 LOPA * Louisiana Organ Procurement Agency - RRR - M iciosoH t ntemel EKpIo 



Hospital Information 



Co<te: ARUA 

N<Hne jjNr7 HOSPITAL OF ARKANSAS* 

Providerc 



Nurrv- 
Hospitafr 
Type*- 



40018 



DeveLr 
Coordinator' 
Team[ 
Corporate; 
Affiliation 
Facility Typel 



n 



Active Q: 
Class] 
Transplant 
Center 



m 



Bed CotiiitL 
ICU Bedr 



Count*- 



Hospital Agreement Information 



Eyebank agreement with[ 
Who signed for hospltal[ 
Titlef 

Date contract received byr 



Type of agreement 
Hospital Agreement Start Oate£ 
Hospital Agreement Expin 



LOPAL 

Date contract signed byr 
lopaL 

Date contract mailed tor 



Contract Addendum 



3 



hospital 1 



IP: 



li 



Services and Miscellaneous 




Address Information 



Address Line 1: |4301 westmarkham 
Address Une 2 J"""""™ ~ 



crty:^; 



TLE ROCK 



$tate: [Arkansas 



Zip| 7220S 



1 



Phone:|~ 
FaxT 



Save& Close 



Hospital Contacts 



No records found! 



Add Contact 
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10.4.3.2 Processing 

Used to View, Edit, or Add a hospital record to the system. 

10.4.3.3 Database Tales Updated 

HospitaLt 

10.4.3.4 Special Edits 

None 

10.4.3.5 Actions 

Save & Close Save data and close the popup window 

Close Close window and cancel any changes 

Add Contact Add a new hospital contact 

Edit Edit/View a contact 

Delete Delete a contact 



10.4.4 View / Edit / Add Hospital Contact 



10.4.4.1 Overview 



««| LOPA - Louisiana Organ Procurement Agency - RRR - Microsoft Inter. 



Contact Information 



Contact ID: [new] 



Prefix: 
Title: 

First Name: 
Middle Name: 
Last Name: 
Suffix: 

Address Line 1: 

Address Line 2: 

City: 

State: 

Zip Code: 

Phone: 

Email Address: 
UNOS Contact 



Save a Close 



~| | Close | 



II 
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10.4.4.2 Processing 

Add/View/Edit contact information. Since several data elements in the R3 database have contact 
information (hospitals, eyebanks, etc.), this is the same screen that is used across the application. 

10.4.4.3 Database Tables Updated 

hospital_contact_t 
contacts 

10.4.4.4 Special Edits 

None 

10.4.4.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 



10.5 Eyebanks 



10,5.1 List Eyebanks 



10.5.1.1 Overview 



3L0PA - Louisiana Organ Procurement Agency - RRR - Microsoft Internet Explorer 

(jfe m 93? ti&sm Safe m> ; 

Home Call Center w Search ^ Management * Toola 



Referrals Reports and Resources 



mm 
mi 



View Eyebanks 



ROWS 1-3 Of 3 


EBBS 


i 1 Code 


i tvebank Flame 




1 State 


j Phone 




SEB 


SOUTHERN EYE BANK 


|Y 3333 


^Louisiana 


1(502)849-2829 ] 


Edit! 


NWLEB 


NORTHWEST UONS EYE BANK 


Y LAFAYETTE 


Louisiana 


(111)111-1111 


IHIfl 


BRREB 


BATON ROUGE REGIONAL EYE BANK 


iY x 


Louisiana 


"1(111)111-1111 ! 



Add New 



Eyebank | 



Current User LWBTZEL 



HMJR. Version 1.09 
Copyright ©2002 LOPA 



Date/Time: 12/17/02 ©*:47:S1 



10.5.1.2 Processing 

This screen present the user with a list of all eyebank records in the system. 

10.5.1.3 Database Tales Updated 

None 

10.5.1.4 Special Edits 

None 
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10.5.1.5 Actions 

Edit 

Add New Eyebank 



Edit the corresponding eyebank record in a new window. 

This button will open a new window to add a new eyebank record 



10.5.2 View / Edit / Add Eyebank 



10.5.2.1 Overview 



*3 LOPA • Louisiana Organ Procuiernen! Agency - RRB - Microsoft Internet Exploiei 



Eyebank Information 



ID42 



Name SOUTHERN EYE BANK 



Active J53 



Comments 



Included Ruleouts: 



Active Viral, Bacterial or Fungal 

AID&H1V+ 

Other 

History of HepatMs 



Stttected 

11f| History of AIDS 
F| History of rW 



Ruleout Information 



Age Accepted Range (MitvMao |j | - 170 | Weight Accepted Range (MirvMa>Q pa3 l - |3utT 



Address Information 



Eyebank Contacts 



Address Line t jAAOASADS 



Address Une 2 jADORESS2^;V 

Cft yj3333 



State ) Louisiana 



23p|l1111 



PhOHe |(S02) 849-2829 ] 
Faxj(S04) 891 3937 ] 



| Action 


Last 


First 


iriin 


Phone I 




DSFFDS toSFSFD (111)111-1111 j 



Add Contact "| 



Save & Close 



] [ Close | 



ffl 



10.5.2.2 Processing 

Used to View, Edit, or Add an eyebank record to the system. 

10.5.2.3 Database Tales Updated 

eye banket 

10.5.2.4 Special Edits 

None 
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10.5.2.5 Actions 

Save & Close 
Close 

Add Contact 

Edit 

Delete 



Save data and close the popup window 
Close window and cancel any changes 
Add a new eyebank contact 
Edit/View a contact 
Delete a contact 



10-5,3 View / Edit / Add Eyebank Contact 



10.5.3.1 Overview 



Q LOPA - Louisiana Organ Procurement Agency - RRR Microsoft rhJcT' 



Contact Information 



Prefix 
Title: 

First Name: 
Middle Name: 
Lost Name: 
Suffix: 

Address Line 1: 

Address Line 2: 

City: 

State: 

Zip Code: 

Phone: 

Email Address: 
UNOS Contact: 



Contact ID: 695 

MS 



Ipsfsfp I 



c 



] 



i DSFFPS 



|fpssfp 



[ 



Ifdsfpsfps" 



Louisiana 



H 



11 



i(ni)iii-iiTr 



r 



Save & Close 



Close 



10.5.3.2 Processing 

Add/View/Edit contact information. Since several data elements in the R3 database have contact 
information (hospitals, eyebanks, etc.), this is the same screen that is used across the application. 

10.5.3.3 Database Tables Updated 

eyebank_contact_t 
contacts 

10.5.3.4 Special Edits 

None 
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10.5.3.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 



10.6 S ystem News and Messages 



10,6,1 List System News and Messages 



10.6.1.1 Overview 



']JL0PA - Louisiana Oigan Piocuroment Agency - RRR • Microsoft Internet txplofOt 



Home Cat! Center ^ Search v Management Tools 



mm 



Referrals Reportsand Resources 




System News and Messages 


Rows 1 - 1 of 1 


Mag 
Action iO 


Message 


Start Date/Time End Date/Time 


fEditl IDeletel 157 > ' ' ' v> 

! welcome to th 


^3 devefopment 


08/01/2002 12/31/2002 
00;00 11:59 


environment 

I. . is 






Current User LWEITZiL " 


| Add Message | 
Copyright ©2002 LOP A 





II. 



10.6.1.2 Processing 

This screen present the user with a list of all system news and messages in the system. 

10.6.1.3 Database Tales Updated 

None 

10.6.1.4 Special Edits 

None 



10.6. 1.5 Actions 

Edit 
Delete 

Add Message 



Edit the system news and messages record 

Delete the record. A confirmation prompt will appear 

Add a new system message 
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10,6,2 View / Edit / Add System Message 



10.6.2.1 Overview 





Message ID: 157 



Message 




f 



Start Date/Tim* 1d84)i/2002 00:Q0 jH 



End Date/Tine |12/31/200211:59 E l 



Save & Close 



it 



Ctose 




u 



J] 



10.6.2.2 Processing 

Used to View, Edit, or Add a system message. System messages are displayed on the home page of 
the R3 application after a user has logged in. The messages are displayed if the current system date 
falls between the start and end date/time for the record. 

10.6.2.3 Database Tales Updated 

System_message_t 

10.6.2.4 Special Edits 

Start date must be prior to end date. 

10.6.2.5 Actions 

Save & Close Save data and close the popup window 

Close Close window and cancel any changes 
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10.7 Im p orts 



10.7.1 Import List 



10.7.1.1 Overview 



I^JlGPA - Louisiana Chgan Piocurement Agency - RRR - MiciosoH Internet Kxplatet 



Home Call Center * Seaich w Management . w Tools 



Referrals Reportsand Resourc 



mmim 



File Import 



Create Import 


| System Status 


Filo Typo: [T^SI®WS3PB £•] 


To import a new tile into the system: 

* Select the type of Import file from the list (OMV or 
Registry) 

> Click on the Browse button to select the file from 
your Local or Network drive to be imported In the 
database. 

* Click import File, to start the import process 


1 Reglstiy Records: 209.592 
OMV Records: 17,292 
I Merged Snapshot Records: 226,884 
| Reglstiy Deleted Records: 0 
I OMV Deleted Records: 1 


File Naiiie:| |Mp^oSS5B| 


| Upload CSV F8e | 





Import History 





! File 


Type I 


Uploaded 


! Imported 


Bytes 


Records 


Valid 


i Loaded j 


Errors 


Status 


| Mewl 
Mewl 

Lmswj" 


Registry 


import Ij 
import 


12/06/200211:11 


12/067200212:13 


'! 35338828 \ 


209592 


209592 


\ 209592 


d 


Complete J 


12/05/2002 22:22 


12/05/2002 22:25 


1624 


9 


1 


1 


8 


Complete 


OMV 


JmpjortJL 


11/25/200212:14 


11/25/200212:16 


I 4944412 jj 


22000 


21956 


1 21912 


44 


'Complete J 


Mewl 


OMV 


Import 


11/25/200212:08 


11/25/200212:10 


4944412 


22000 


21956 


21912 


44 


Complete 


Mewl 


J?egistry 


Import II 10/28/200213:47 


107287200213:48 


17563 ! 


191 


. .lit . 


1 o 


0 


'Complete j 


Mewl 


Reflistry 


Import 


10^25/200214:39 


10/25/2002 14:40 


17563 


191 


191 


191 


0 


Complete 


' Mewl ' 


Registry 


Import i 


09/1572002 16:28 


09/1 8/2002 16:29 


94151 ; 


1174 


1163 


I 0 


11 


Complete I 



10.7.1.2 Processing 

This page is used for importing Registry and OMV data into the R3 application. On this page, there 
are no imports currently being processed. The use has the option of importing a new file, or viewing 
and existing import that has already taken place. The system status window shows the current record 
count of the Registry and OMV tables in the system. 

For more detail on the import process, please see the import export detail design section. 

10.7.1.3 Database Tales Updated 

None 

10.7.1.4 Special Edits 

None 



10.7.1.5 Actions 

Upload CSV 
View 



Upload a new Registry/OMV CSV file to the system 
View a prior import record 
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10.7,2 Import Current Status 



10.7.2.1 Overview 



3|L0PA - Louisiana Oioan PiMCtiieinent Agency - RRR Microsoft Internet (Igniosei 

§£> gsp Wan %/!3^3 

Home Call Center " Search v Management ~ Toots 



mm\ 



Referrals Reportsand Resources 



File Import 



Current Import Status 


System Status 


File Name: F2l233/aucm.s|)p File Records: 0 Current Status: Uploaded 
File TVpe: OMV Validated Records: 0 Upload Completed: 12/17/2002 08:51 
File SubType: bitpoit Imported Records: 0 import Completed: 
File Size: 495 bytes Error Records: 0 


Retfistiy Recoi Us: 209.592 
OMV Records: 17,292 
Merged Smipslwt Recoi (Is: 220,884 
Reolstiy Deleted Records: 0 
Or.1V Deleted Recoi (Is: 1 


| Refresh | 





import History 



Pi M Mill 


File 


Type | 


Uploaded 


Imported 


1 Bytes 


| Records 


I Valid 


Loaded 


Errors 


I Status j 


Mewt 




Import [ 


12/06/2002 1.1:11 


12/08/200212:13 


jl 35338828 


:: 209592 


.209592 


: 209592 


0 


Complete j 


Mewl 


Registry 


import 


1 2/0572002 22:22 


12m&f2002 22:25 


1624 


9 


1 


1 


8 


Complete 


tMfiwJ 


OMV 




" 11/25/2002 12:14 


11/25/200212:16 f 494441 2 


1 22000 


21956 


! 21912 


44 


Complete ] 


Mewl 
r Mewl " 


OMV 


import 


11/25/2002 12:08 


11/25/200212:10 


4944412 


22000 


21956 


21912 


44 


Complete 


Registry 


import | 


10728/2002 13:47 


10/28/200213:48 


T 17563 


I 191 


191 


! 0 


0 


Complete 1 


Mewt 


Registry 


Import 


10/2572002 14:39 


10725/2002 14:40 


17563 


191 


191 


191 


0 


Complete 


7 Mewl ' 


Registry^ 


import J 


09/18/2002 16:28 


09/18/2002 16:29 


!| 94151 


li 1174 


1163 


0 


11 


Complete J 



10.7.2.2 Processing 

Once an import has been started, the screen changes as above to show the current status of the 
import running in the system. While the import is running in the database backend, the user can 
refresh the information to view record counts, errors, and the current status of the process. 

10.7.2.3 Database Tales Updated 

Import_Export_T 

Registry_t 

OmvJ 

Omv_reg_snapshot_t 



10.7.2.4 Special Edits 

None 
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10.7.2.5 Actions 

Refresh 
View 



Update the current status 
View a prior import record 



10,7,3 View Import 



10.7.3.1 Overview 






File Name: F23385/I 3coitvert.csv 
File Type: Registry 
File SubType: Impoit 

File Size: 35,338,828 bytes 



File Records: 200,502 
Validated Records: 209,502 
Imported Records: 200,502 



Current Status: Complete 
Upload Completed: 12/06/2002 11:11 
Import Completed: 12/06/2002 12:13 



Error Records: 0 



i! 



10.7.3.2 Processing 

This page is a view of an individual import process that has already taken place. This allows a user to 
view the statistics of an import along with the orginal CSV file, the log file generated by the import 
prcoess in the database, and an error file which contains the actual records from the CSV file that 
could not be loaded due to errors. 

10.7.3.3 Database Tales Updated 

None 

10.7.3.4 Special Edits 

None 

10.7.3.5 Actions 

View CSV File Popup window showing CSV file 

View Log File Popup window showing Log file 

View Error File Popup window showing Erro file 
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10 . 8 Gen e ral Lo oku ps 



10.8,1 Maintain General Lookups 



10.8.1.1 Overview 



Pjj ^LOPA - Louisiana Organ Procurement Agency - RRR - Microsoft Interne! Cicpioier 



Home Call Center w Search ~ Management * Tools 



Referrals Reportsand Reeourc 



General Lookups 



Lookup Tables 



Lookup Values 





Action Type 






Age tints 






Agency 






Agreement Type 






Beeper Type 






Btood CdtoKi Type 






Body Identification 






Body Part 






Body Released to (Tissue) 






Cause of Death 






Circumstance of Death 






Consent Approacher 






Consent lem 






Consent Obtained Type 






Crystalloid Type 






Culture Body Part 






CuJure Result 






Cuftures 






Death Type 






Division 






Donor History ID 







1 — 


Action 


1 Active 


\ Code 


j Label 


Description 




i£djfl 


fUol fDownl 


m 


1 


Coroner 


'Poroner 


i 
I 


rEdlfl 


fUDl fDownl 


o 


UNR1 


Unresolved 


Unresolved 




lEdlfl 


IUdI fDownl 




2 


Written 


^Written 


I 


Edit} 


lUol fDownl 


m 


3 


Face To Face 


Face To Face 




fEdltl 


RJpl fDownl 


B 


4 


Face To FaceA/Vritlen 


jFaceTo FaceiWriiten 




HEditl 


fUol fDownl 




5 


Funeral Home 


Funeral Home 




Edit! 


fUol fDownl 




6 


Phone 


jPhone 

ii 


! 


fEditi 


[Up! fDownl 




7 


Phone and Written 


Phone and Written 




1 EdJi 


fUol fDownl " 


'•' m 


8 


Other 


!5lher 


i 



Add Value |f Update Active~l 



ii 



10.8.1.2 Processing 

This screen is used for maintaining the generic lookup tables and values in the system. From here an 
administrator, can look at the lookups for a given table, edit the values, change the order in which te 
appear in drop down lists, and also deactivate values no longer used. 

10.8.1.3 Database Tales Updated 

Lookup_values_t 

10.8.1.4 Special Edits 

None 



10.8.1.5 Actions 

(select table) 

Edit 
Up 

Down 
Add Value 
Update Active 



Selecting a table from the list on the left will refresh the screen and 

display the values for the selected table on the right. 

Edit the table values 

Move the order up by one 

Move the order down by one 

Add a new value for this lookup table 

Update the active flags for the table values 
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10.8.2 View / Edit / Add Lookup Value 



10.8.2.1 Overview 




1 




Active? 



Description 



Label 



Lookup Table: Contact Type 



Value | 



Coroner 



Coroner 



Save& Close I Close 




m 




10.8.2.2 Processing 

This screen allows the View, Edit, or Add of an indiviual lookup table value. 

10.8.2.3 Database Tales Updated 

Lookup_values_t 

10.8.2.4 Special Edits 

Value Certain values can have up to 2 more corresponding values. If this is needed, then 
the extra values and labels will be displayed to the right for data entry. This is controlled 
by ionformation on the actual lookup table. 

10.8.2.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 
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1 0.9 Interview Que stions 



10.9.1 List Interview Questions 



10.9.1.1 Overview 



-3L0PA - Louisiana Oigan Procurement Agency - RRR - Microsoft internet Exploier 



0b g& ^©a &mm 2^ 



Home Citit Center Search w Management v Tools 



Referrals Reportsand Resources 




Interview Questions 



I 



ROWS 1 • 42 Of 42 



fEdm IUp] IDownl 1 Y Genera! Health Information 
fUol IDownl 2 N General Health Information 



Version 2 question 1 



Version 2 question 1 



iEdifl Did (Downl 3 Y General Health Information 



EtiiO fUp) ID own! 4 Y General Hearth Information 



fEditl rupl rDownl 5 Y General Health Information 



Edit] PJpI IDownl 6 Y General Health Information 



Please name any major General health information. Tne 
illness or surgical answer to this question may evoke 

procedures that the memory of other medical problems 
potential donor has had in in the past If prior surgery, be sure to 
the past When (dates)? ask reason for procedure. 



{Subquestions 



What medications, if any, 
did the potential donor 
take on a regular basis? 
Was the potential donor 
allergic to any 
medication? 



The use of certain medications may 
show extent of disease process and 
may be used to evaluate medical 
suitability, If name of medication is 
not known, ask if they know why the 
patient was taking the medication. 
Do not make le ading questions. 



Old the potential donor 
use tobacco products? 
Cigarettes? Packs per 
day? For how long? Other 
tobacco products?ss 

Did the potential donor 
drink alcohol? How 
much? What type? How 
long? 



Use of tobacco products increases 
the incidence of cancer, cardiac and 
pulmonary diseases. Use may be 
factor in overall medical suitability.ss 

The nutritional effects of alcoholism 
impact on the quality of tissue, If 
patient Is a known alcoholic, be sure 
to get height and weight to determine 
if patient Isano rexic or wasting. 



What was the potential 
donors occupation? Has 



Ask for current occupation and if 
retired from which occupation. Ask of 



l.'.JLjiriM 



10.9.1.2 Processing 

This screen allows the user to view the interview question in the R3 application. These questions 
along with their subquestions are used in the Medical Social history section of a referral. Interview 
questions in the database are versioned so that when the question or subquestion data is changed, a 
new record is created. 

10.9.1.3 Database Tales Updated 

None 

10.9.1.4 Special Edits 

None 



10.9.1.5 Actions 

Edit 
Up 

Down 

Add New Question 



Edit the question 
Move the question order up by 1 
Move the question order down by 1 
Add a new question 
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10.9,2 View / Edit / Add Interview Question 



10.9.2.1 Overview 



<3 LOPA - Louisiana Oigan Piocuiemcnl Agency - RRR - Miciosoft Internet Explmei 



Question 85 (Current Information) 



Question »S (New Information) 



Category: | General Health information jgj 



Question; 



Guidance: 



Did the potential donor drink alcohol? How much? g 
v*forttype? How long? 



The nutriUonol effects of alcoholism Impact on the 
quafty of tissue. If patient is a known alcoholic, be 
sure to get height and weight to determine if patient 
is anorexic or westing. 



m 



Comment Prompt 



Stait Date/Time: [11/05/2002 1&1 8 [ 
End Date/Time: f~ |P°l 



Copy and Eca [ 



Save a Close I Close 



Subqucslions 



ST Action 


3 


Active 


Category 


Question 


Guidance || 


iEditl fUol fDowni 1i Y 

I 

\ I . 
! f 

■ 


General Health Information Rid the Types of alcohol: beer, wine, hard liquor, etc. Amount 
potential number of drinks per day, volume consumed per day or 
donor drink week, Avoid use of term ^social drinker^ give 
alcohol? amountffrequency.The nutritional effects of alcoholism 

impact on the quality of tissue, if patient is a known 
ddddd alcoholic, be sure to get height and weight to determine 

if patient is anorexic or wasting. i 


j Add New SubQuestion j 



fa 



10.9.2.2 Processing 

From this screen the question and subquestion information can be maintained. The existing question 
information is displayed along with the list of subquestions attached. 

10.9.2.3 Database Tales Updated 

Question_t 

10.9.2.4 Special Edits 

Start Date/Time If a question start date/time is greater than the current date, then the 

user is allowed to change the question information. Otherwise this data is protected. 

Copy & Edit This will cause a new versionof the question to be created which can then be 
edited. 
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10.9.2.5 Actions 

Save & Close 
Close 

Copy & Edit 

Edit 

Up 

Down 

Add New Subquestion 



Save data and close the popup window 

Close window and cancel any changes 

Copy the question data to a new record for editing 

Edit the subquestion 

Move the subquestion order up by 1 

Move the subquestion order down by 1 

Add a new subquestion to the list 



10,9,3 View / Edit / Add Interview Subquestion 



10.9.3.1 Overview 



LOPA * Louisiana Organ Procuiement Agency - RRR - Miciosufi Internet Cxplwer 



SubQucstian #1 (Current Information) 



Suhcttteyoty 



Question 



Guidance 



I General Heaflh Information 



Did the potential donor drink alcohol? 
ddckld 



Types of alcohol; beer, wine, hard liquor, etc. 
Amount number of drinks per day, volume 
consumed per day or week. Avoid use of term 
^social drinker^ give amount/frequency Jhe 
nutritional effects of alcoholism Impact on the 



IF YES, WHAT TYPE? 
HOW OFTEN? 
Comment Prompt FORHOWtONG? 



Start Dateffii ne: fti/reaotBiS-iT 
End Date/Time: 1 ~~ 



la 



SubQucstion #1 (New Information) 



Copy and Edit | 



Save & Close I Close 



10.9.3.2 Processing 

From this screen the question and subquestion information can be maintained. The existing question 
information is displayed along with the list of subquestions attached. 

10.9.3.3 Database Tales Updated 

subquestion_t 

10.9.3.4 Special Edits 

Start Date/Time If a subquestion start date/time is greater than the current date, then 

the user is allowed to change the subquestion information. Otherwise this data is 
protected. 

Copy & Edit This will cause a new version of the subquestion to be created which can then 
be edited. 
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10.9.3.5 Actions 

Save & Close 
Close 

Copy & Edit 



Save data and close the popup window 

Close window and cancel any changes 

Copy the question data to a new record for editing 



10.10 



Consent Addendum Text 



10.10.1 View Consent Addendums 



10.10.1.1 



Overview 



«3|L0PA - Louisiana Organ Procurement Agency - RRR - Microsoft Internet Exptoier 

@fe m %xdtes Safe 



Home Call Center ^ Search w Mansnement ^ Tools 



Referrals Reportsend Resources 



Consent Addendum - View 



R0W81 -9 Of 9 



Action |Vernion ID j Start Date/Time | End Date/Time [Referrals 



rCoovandAddl 92 0904/200215:29 



fCoovandAddl 
jpQpy and aaai 

[QftPY ?nti Ad<31 
fCopvandAddl 



91 09/24/2002 1 5:28 09/24/2002 1 5:28 
90 09/24/2002 1 $:WMffif2to?i5ar 

m 



84 09/24/2002 14:15 09/24/2002 15:22^ 
47 09/20/2002 08:00 09/24/2002 1 4:1 4 
11 69/01/2002 1 0:1 0 09/20/2002 07:59 " 



iCQPY^n<IAflOI, 



01/01/2002 00:00 09/01/2002 1 0:09 



01/01/2001 00:00 12/31/2001 23:59 



Add New Consert Addendum 



Addendum Text: (09/24/2002 15:23 - 09/24/2002 15:26) 



Here's a brand new consent addendum that takes effect Monday 
September 20, 2002 at 8:00 AM. 



10.10.1.2 Processing 

View, Edit, Add consent addendum information in R3. The consent addendum text is used on call 
center pages and is also versioned. This will insure that the consent text does not change for prior 
referrals in the system. 

10.10.1.3 Database Tales Updated 

consent_addendum_txt_t 



10.10.1.4 Special Edits 

Start date/time If the start date/time of the latest addendum record is in the future, then the 
Edit option is avaialable to the user since this has not yet been used. Otherwise the Copy 
and Add function is presented so the user can create a new record. 

Addendum TextTo view the addendum text for a particular record, simply move the mouse 
over that row and the text will change dynamically. 



10.10.1.5 Actions 

Edit Edit the consent addendum text 

Copy and Add Copy this text and add a new record 

Add New Add a new record that is blank 
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10,10.2 View / Edit / Copy Add Addendum 



10.10.2.1 



Overview 



^3 LOPA - Louisiana Organ Piocurement Agency - RRR * Microsoft Internet Explorer 




Consent Addendum Text 



Message ID: [new] 
Start | 



Date/Time:* 
Consent 
Text: 



ICS! Leave blank to use the current date/time. 



Here's a brand new consent addendum that takes effect Monday September 20, 2002 at 8:00 AM. 



m 



) Save a Close | Close | 



10.10.2.2 Processing 

Edit a consent addednum record 



10.10.2.3 Database Tales Updated 

Consent__addendum_txt_t 

10.10.2.4 Special Edits 

Start date/time Date must be today or higher 



10.10.2.5 Actions 

Save & Close Save data and close the popup window 
Close Close window and cancel any changes 
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[1 0. 11 Help Wi ndow Mainten a nce 



10,11,1 Help Maintenance 



10.11.1.1 



Overview 



'3 LOPA - Louisiana Oiyan P»ocuiement Atjcncy FtHR • Microsoft internet L »pk»ei 

Home Call Center w Search » Management * Tools ' Help * Logoff 



Referrals Reports and Resources 



Help Window 



Ca3 Cent?> ♦ Acton Loo 



Help Maintenance 



Cel Certer - Blood Volume 

Cal Center - Consort Ma 

Cal Center - Enter New Referred 

Cal Center- Wain Entry 

Cat Certer- Med/ Social tfstory 

CaJ Certer - RUeout Reason 

CaJ Certer - Screening 

Donor 

Main 

Management • Audi Data 
Managemeri - Concert Addenda 
Management - EyebanJcs 



Managemert - Hetp VMndow Mottenance 



Management - fenports 
Managemert - Werview Qj es Uona 
Management - OPOs / frganrratjons 
Managamert - Setxriy Profiea 
Managemert - System News and Messages 
Managemert - Users 
Managemert • Wets Action Maintenance 
Managemert - Web Menu Maintenance 
Message Log 



Help Text 


He tp Text 




«b>Hes3 for CC Action Lcg.«*xbr> 






id 








II 


[Save) 




i 


Help Preview 






[Help tot CC Action Utj. 



J 




10.11.1.2 Processing 

Used for editing the help pages for each window/screen in the R3 application. The help text created 
here is presented to the user when they select the Help link from an R3 web page. 

10.11.1.3 Database Tales Updated 

Window_help_t 



10.11.1.4 Special Edits 

WindowSelectlng a window from the list on the left will load the help text for that window in 

the help text column on the right for editing. 
Help Text Any text can be entered here in HTML format. 

Help Preview This window dynamically changes as the user is typing data in the help text 
window. This allows the user to see a live preview of the help page before they save the 
data. 



10.11.1.5 Actions 

Save Save the help text 
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10.12 Audit Data 



10.12.1 Audit Search Form 



10.12.1.1 Overview 



!>3LGPA - Louisiana Oigan Piocuiernent Agency - RRR - Microsoft Internet Explorer 



Home Call Center ▼ Search * Management ^ Tools 



Referrals Reporisand Resources 



mmm\\ 



Audit Search Form 



Search Fillers 




Instructions 



* Enter search criteria to search for audit records in the 



> Select your sort order and records per page below. 

> Hit Query to see the results. 




10.12.1.2 Processing 

This form is used to search for audit records in the R3 application. The search filters available are 
presented on the left side of the screen. Instructions and result options are displayed on the right 
This form allows the user to specify how they want the results sorted, and also how many records of 
the result should be displayed per page. 



10.12.1.3 

None 



Database Tales Updated 



10.12.1.4 

None 



Special Edits 



10.12.1.5 

Query 



Actions 



Execute the query 
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10.12.2 Audit Search Results 



10.12.2.1 Overview 



n 



'3jL0PA - Louisiana Oigan Ptocwement Agency - RHR ♦ Miciosoft Internet Exploiei 



Home 


Call Center " Search 


w Management 


Toots 


Help v Logoff 


Referrals 


Reportsand Resources 


ROWS 11 -20 Of 9,977 


Audit Search Results 


<]<) FIRST || < PREVIOUS | 


| NEXT f> || IAST f>f> 


| Action 


| Aud rt Date /Time 


I IP Address 


H User Name 


| Command I 


[DetailsWMUl 


jjl 1/1 8/2002 09:41:33 (Mon) 


|'208.224,173.2 


| f ADMIN USER 


'Vefbrgan.updlniFhys-vlewlnji ] 




11/1672002 09:42:09 (Mon) 


208.224.173.2 


AOMIN USER 


reforgan.updlnllPrrys-vlewlnlt 


IDetaiisfXMDl 


!l 1/1 8/2002 09:10:28 (Mon) 


1208.224.173.2 


;|adminuser 


^refmain.vle^oiTjespona^nce j 


IPetailspqwui 


11/15/2002 09:13:21 (Frl) 


208.224.173.2 


ADMIN USER 


refmafn.vlewCorrespondence 


tDatailsfXMUl 


•111/06/2002 12:02:50 (Wed) 


(•208722^173.2 ~ 


! r AOMINUSER 


ilrefmaln.vlewAiog | 


fDetailsfXMUl 


11/067200212:02:35 (Wed) 


208.224.173.2 


ADMIN USER 


refmain.updAlogForm 


!|P<?tail$ftMUl 


]|1 1/0672002 12:02:57 (Wed) 


1:208.224.173.2 


I'ADMIN USER 


; lrefmain.updAlogForrn j 


(DetailsfXMDI 


11/06/2002 12:02:00 (Wed) 


208.224.173.2 


ADMIN USER 


refmain.searchResults 


IPetail?(XMU)l 


1111/1 2/2002 09:44:1 7 (Tue) 


|j208.224.173.2 


IfADMIN USER 


jjrefrnain.searchResuits ] 


IPetaiisCXMUl 


11/18/2002 09:1 0:1 4 (Mon) 


208.224.173.2 


ADMIN USER 


refmain.searchResuits 




10.12.2.2 Processing 

Display the audit search results. The command is the internal command used by the R3 web 
application and relates closely to the screen/window names where possible. 

10.12.2.3 Database Tales Updated 

None 

10.12.2.4 Special Edits 

None 



10.12.2.5 Actions 

Details(XML) 

First 

Previous 

Next 

Last 



Display the details for the record in XML format 
Display first page 
Display previous page 
Display next page 
Display last page 
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10.12.3 View XML Details 



10.12.3.1 Overview 



*5 hUps://r3deY:7?78/p!s/f3dev/docs/audiLxml?ac 



- <parameters> 

<action>refmain.updAlogForm</action> 
<actionJogjd>81292</actionJogJd> 
<description>Entered initial information. </description> 
<refid>45794</refid> 
<user_nm>KBARKER</user_nm> 
<w_dspLayout>Blank</w_dspLayout> 
</parameters> 



11 



10.12.3.2 Processing 

This page is an XML representation of audit data. When any page is requested or submitted in the R3 
application, all form data variables and other system variables are saved to the database. This screen 
shows the user all the data present on the screen when the user clicked an action. 
For example, in the above record the user created an action log in the system. The following data was 
recorded from user entered data and system data: 



action 

actionjogjd 

description 

refid 

user_nm 
w__dspLayout 



refmain.updAlogForm 
81292 

Entered initial information 

45794 

KBARKER 

Blank 



10.12.3.3 

None 

10.12.3.4 

None 



Database Tales Updated 
Special Edits 



10.12.3.5 

None 



Actions 



Page 62 



February 3, 2003 



11 WEB_FIELD_EDITS_T 

ll/l Overview .... 

WEB_FIELD_EDITS_T defines how form elements are to be displayed on a page. In R3 PI-/SQL 
applications, the HTML syntax for form elements should not be coded by hand. Instead, calls to the 
appropriate Field package procedures should be made for painting any given form element on a page. 
The first parameter to the Field label procedures (Iblf and Iblp) and field procedures (fldf and fldp) 
identify the specific row in web_field_edits_t that contain the attributes and specifications for drawing 
a given form element. The first parameter should be match the pattern xxx.yyy, where xxx 
corresponds to a value contained in TABLE_NAME and yyy corresponds to a value contained in 
FIELD_NAME in web_field_edits_t. These two columns uniquely identify a row in web_field_edits_t. 
The Field package procedures will use the attributes defined in a form element's web__field_edits_t 
entry to draw the form element on the page. 

Below is an example of a call to the Iblf function for drawing the label for the Referral Date/Time: 

Field. Iblf ( 1 ref erral__t . ref erral_dttm 1 , TRUE) 
Below is an example of a call to the fldf function for drawing the field for the Referral Date/Time: 

Field. fldf ( 'ref erral_t. ref erral_dttm ' , '01/01/2002 10:00' , 1 , TRUE, FALSE) 

11.2 Tabl e Descri ption 

Below is a list of all of the columns in web_field_edits_t and how they should be used: 



Column 



Description 



TABLE NAME 



Required. In most cases, the name of the database table that contains the 
column listed in FIELDJMAME. 

If FIELD_NAME corresponds to the value contained in LK_VAL2_NAME or 
LK_VAL3_NAME for an entry in LOOKUP_VALUES_T, then TABLE_NAME should 
correspond to the value for LKJMAME. 

TABLEJMAME may be 'webonly' for fields that do not correspond to a database 
table. 



FIELD NAME 



Required. In most cases, the name of the database column that is contained in 
the table listed in TABLEJMAME. 

If TABLE_NAME corresponds to the value contained in LKJMAME for an entry in 
LOOKUP_TABLES_T, then FIELD_NAME should correspond to the value for 
LK_VAL2_NAME or LK_VAL3__NAME. 



DATA_TYPE_CD 



Required. Must correspond to DATA_TYPE_CD in W E B_D AT A_TY P E_T . Current 
allowed values are as follows: 



Code 


Name 




Description 


A 


Alpha 




Alphabetic characters only A-Z,a-z 


AN 


Alphanumeric 




All characters including special 


C 


Checkbox 




One checkbox with a value 


DT 


Date 




Date only (10 bytes for yyyy/mm/dd) 


DTM 


Date / Time 




Date and Time 


EM 


Email 




Email address 


F 


File Upload 




USed for file upload import processes 


FN 


Floating Point Number 


Numeric data with 0-9 and , and - and . 


LC 


Lookup Multiple - 


Checkbox 


Multiple table lookup using a checkbox 


LM1 


Lookup Multiple - 


1 


Multiple lookup using 


Windows 




<SELECT><OPTION> 


LM2 


Lookup Multiple - 


2 


2 windows lookup using 
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Windows 


LR 


LookuD Sinale - Radio 


LS 


Lookup Single 


N 


Numeric 


PH 


Phone 


PW 


Password 


RE 


Regular Expression 


SSN 


Social Security Number 


TM 


Time 


TX 


Textarea 


ZIP 


Zip Code 



<SELECT><OPTION> 

Single lookup using radio buttons 

Single lookup 

Numeric characters only 0-9 

US Phone number with (xxx) xxx-xxxx 

Password Prompt 

Used for custom regular expression 
validations 

Standard social security number as 
999-99-9999 

Time format in HH:MM:SS PM 
Multiline window for comment and large 
text 

Zip code as 99999-9999 (with optional 
4 digit) 



LABEL 



Required. The text label that would appear next to a web page object. 



COMMENTS 


Anv rnmmpnl"? rhp ripx/plnnpr fppK would hp hplnful 


MIN_LENGTH 


Not m^pH 


MAX_LENGTH 


A numhpr inrlirarinn fhp mavimum Ipnnth nf pntprahlp data for innut tpxt fields 


COLSIZE 


A numhpr inrMrafinn thp numhpr nf rolumns fnr tpytarpas fDATA TYPE CD = 

n 1 1 u 1 1 1 uci 1 1 ilj iL>a li 1 i y li ic iiuiiiuci lvi luiui i i i is iui lca lcj i taj ^ i #\ i i i i— ^ i— ' 

TX') or the displayed length of input text fields. 


ROWSIZE 


A numhpr inrlirarinn rhp numhpr nf rnws fnr tpyfarpas fDATA TYPF CD = *TX'^ 

r\ I | LI 1 1 1 L/C 1 IIIUILiQLIIiy LI IC 1 1 Li 1 \ 1 UC 1 Ul I \J VV 9 1 \J 1 ICAlu 1 COO ^ 1— ' # \ 1 / » 111 I— >— \S — ~ I /X J 

or multi-select lists (DATA_TYPE_CD = *LM1' or *LM2'). 


LK TABLE 


The name of a database table that will be used to populate database-driven 
select lists (DATA_TYPE_CD = *LS', 'LM1', or % LM2'). The table used is often 
LOOKUP_VALUES_T, but any database table may be used. 


LK.VALUE 


The database column from the table listed in LK_TABLE that will be used to 
populate the <OPTION> values for a database-driven select list. 


LK_DESCRIPTION 


The database column from the table listed in LK_TABLE that will contain the text 
that appears in a database-driven select list. 


LK_FILTER 


Code that will be used to format the WHERE clause in the SQL statement that 
retrieves the information to populate a database-driven select list. 


PRELOAD_VAL 


A comma delimited list that will be used to populate the <OPTION> values for a 
hard-coded select list. 


PRELOAD_DESC 


A comma delimited list that contains the text that appears in a hard-coded 
select list. 


ONCHANGE 


JavaScript code that will be executed by the field's onChange event. 


ONFOCUS 


JavaScript code that will be executed by the field's onFocus event. 


ONBLUR 


JavaScript code that will be executed by the field's onBlur event. 


ONCLICK 


JavaScript code that will be executed by the field's onClick event. 


SOURCE_CD 


Required. Must be D (for database field) or S (for source, or typically a web- 
only field.) Default is S. 


OPTBU\NK 


For drop-down lists, signifies whether or not a blank or other option should 
appear as the first option in the list. Set to Y in order to have a blank or other 
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option as the first option in the list. 


BLANKVAL 


If OPTBLANK is Y, this column would contain the value associated with the blank 
or other option that appears as the first option in the list. 


BLANKDESC 


If OPTBLANK is Y, this column would contain the description associated with the 
blank or other option that appears as the first option in the list. 


ONKEYUP 


javascript cooe unai win ue executeo Dy tne neia s oniseyup event, lypicaiiy 
used to dynamically change DIV values on the page as the user keys in data 
stroke-by-stroke (for example, in calculating numeric totals on the fly.) 


CHECKBOX_SEP 


i exc. or n i riL mat win ue piaceu uetween eacn option ror a raaio Dution. 
Default is non-breaking space, but value here would typically be a <BR> if radio 
button options are to be listed vertically as opposed to horizontally. 


MIN 


C r\ r n 1 1 rr\ a r i /~ anH flnaf inn nninf nnmharc cnorifioc fho minimum 10 f- h 3 1" m 1 1 ct" 

ror numeric ana iiuatiny point numuers, specifies trie minimum value trial uiubt 
be entered by the user. If a value is specified here, a value must be specified 
for MAX as well. 


MAX 


For numeric and floating point numbers, specifies the maximum value that must 
be entered by the user. If a value is specified here, a value must be specified 
for MIN as well (see below.) 


LK_SORT 


Thp HafahAQp rnhimn frnm fhp fahip liQfprl in 1 \C TARI F t"haf will hp iiQprl fn ^nrt 
i i ic uaiaufldc luiu i i ii i 1 1 ui 1 1 li ic tauic iolcu ii i i— r\ i hull li lai win uc ujcu iu jui l 

a database-driven select list. 


UCASE 


Indicates whether or not the data contained in the form element is to be 
displayed in upper case. The default is 'Y'es for virtually all application 
elements. This value should be set to 'N'o for any elements that should be case- 
sensitive. 
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12 Crystal Enterprise API 



12.1 Overview „___________„ 

This document outlines the designs for the interfaces needed for the R3 web application to 
communicate with the Crystal Enterprise installation for LOPA. This includes use management, and 
execution of reports from the R3 web pages. 



12.2 User Synchronization 



12,2.1 ChangeUser.csp 

A crystal server page (.csp) will be created to facilitate synchronization of user ids and passwords 
between R3 and Crystal Enterprise. This page will be called via PIVSQL in R3 to update user 
information as well as open a report in a report viewer. 



The parameters are: 



action The action to perform (add,change,delete,run) 
userid The user id to be updated (valid with add, change or delete actions) 
password The password for the user id (valid with add, change or delete actions) 
name The first and last name of the user (valid with add, change or delete actions) 
status Status code of the user id (I=Inactive,A=Active) (valid with add, change or delete 
actions) 



An example of a user admin call might be: 

http://sei^er:port/cr7stal/enterprise/lopa_admin/ChangeUSer.csp?action=add&userid=lweitzel&pa 
ssword=xxx8mame=Lance%20Weitzel&status=A 

This will add user Iweitzel to the crystal enterprise with a password "xxx" and status=A for active 

Processing: 

The CSP will add crystal users with the ability to change passwords set to "NO". This way user 
passwords can't be changed by users unless it is done from R3 web application. 

Return: 

The CSP will return an XML response indicating if the Crystal user modification was successful. 
The XML DTD is as follows: 



<?xml version= M 1.0 M encodings UTF-8 M ?> 
<!ELEMENT code (#PCDATA)> 
<! ELEMENT message (#PCDATA)> 
<! ELEMENT response (code, message)> 

Sample XML: 

Sample XML response: 
<?xmJ version="1.0" encoding="UTF-8"?> 
<response> 
<code>3 2</code> 

<message>User ID already exists!</message> 
</response> 



12.3 Report Execution 



12,3.1 Non-managed Reports 



A crystal server page (ChangeUser.csp) will be created to facilitate a secured call to open a non- 
managed report in Crystal Enterprise. This page will be called via PIVSQL in R3 in a new window to 
pass parameters and open a report in a report viewer. 

The parameters are: 

action The action to perform (run) 

rpt Title of Report to run (valid with run action only) 

nump Number of parameters (valid with run action only) 

init Specifies viewer type (actx, nav_plugin, java, java_plugin, html_frame )(valid with run 

action only) 

cmd Directs that the report be exported (EXPORT is the only valid value) (valid with run 

action only) 

promptX Where X is (0 to n) parameter values (valid with run action only) 
EXPORT_FMT Specifies the export format if cmd value is EXPORT (valid with run action only) 
Valid values are listed below: 



Export Format 


Export_FMT Representation 


Adobe PDF 


U2FPDF:0 


HTML 3.2 


U2FHTML:2 


HTML 4.0 


U2FHTML:3 


|Crystal Reports (RPT) 


U2FCR:0 


|Excel 7.0 (XLS) 


U2FXLS:5 


|Excel 7.0 (XLS) Extended 


U2FXLS:6 


Rich Text Format (RTF) 


U2FRTF:0 


Word Document (DOC) 


U2FWORDW:0 


XML 


U2FXML:0 



An example of a user admin call might be: 

http://server:port/crystal/enterprise/lopa_admin/ChangeUSer.csp?action=run&rpt=World% 
s%20Report&nump=2&init=java&cmd=&EXPORT_FMT=&promptl = 1234&prompt2=Smith 



Processing: 

This will RUN the World Sales Report, which has 2 parameters, in a JAVA viewer. The report will 
not be exported directly and the first and second parameter values will be 1234 and SMITH 
respectively. ChangeUser.csp will do a response. redirect call so to maintain the calling R3 screen 
the above url should be called with a window. open to launch into new page. 



Return: 

The CSP will return an XML response indicating any processing error or will load the report upon 
success. 



12,3,2 Managed Reports 



Managed reports will be accessed through a separate interface but a link to this application will be 
available within an R3 screen. 



13 Versions 



1 3. 1 New versions of R3 



As defects are identified and fixed, and as LOPA requests changes and enhancements to existing 
functionality, or new functionality, these bugs and changes requests are captured using the BugTrack 
application. Based on the relative priority of these requests, they are gathered together and 
implemented as a new release of the application. 

Once individual BugTrack items are completed (including unit and system testing), they are updated 
to a "Complete" status. This marks them as eligible for inclusion in a future release. Generally, all 
"complete" items are swept up and included in the next release. Based on the work completed for 
each individual item (e.g., the individual stored procedure(s), functions(s), database table changes, 
graphics or other static content), the development team prepares a migration list that includes all the 
changed and new application components. The migration list also serves as a checklist, allowing the 
developer performing the migration to check off all the individual application components that need to 
be moved from the development environment to the test environment, tested, and then moved from 
the test environment to the LOPA production environment. This migration list, together with the 
individual BugTrack items, forms the basis of the release notes that describe exactly what is being 
implemented in that release. 

After the release has been completed, the BugTrack items are updated to a "closed" status, with the 
release date updated to the date the item was released to production. 



13.2 Version 1.0.5 



Bugtracks 



265 - Sort for call center search 
362 - Sensitivity 
381 - Email for message logs 
401 - Register rotating cube 

403 - Move cardiac tab 

404 - Move Caval Patch INd 

405 - Heart dropdown checkboxes 

406 - Ruleout for Eye/Tissue 

408 - Change Check if Active on User screen 

410 - Custom logoff page 

413 - Locality code 

417 - Eyebank age limits 

420 - Unlock correspondence log for locked referrals 

429 - ORA error on tracking page 

430 - ORA error in Tissue Serology 

431 - Staff names picklist 

432 - Not saving address on DOnor Personal 
435 - Sort system messages 



Packages 
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JMCS 



CallCtrPkg 

CorrespondencePkg 

MainPkg 

MessageLogPkg 

RefBasicPkg 

RefKidneyPkg 

RefLabPkg 

RefOrganPkg 

RefUtilPkg 

Ses 

WebPkg 



Static HTML 



None 



Database Changes 



alter table message_log_t add (email varchar2(75)); 

alter table tissue_serology_detaiLt modify (counter number); 

UPDATE REFERRALJT 
SET LOCALITY_CD = 'L' 
WHERE LOCALITY_CD IS NULL; 

update web_field_Edits_t 

set label=Tx Center/OPO:' 
where table_name= , culture_reportto_detaiLt' 

and field_name='opo_id'; 

—In web_field_edits_t, modified the entries where table_name = 'hearty and field_name = 

'anatomicaUnd', , cv_disease_ind' / and 'surgicaLdamageJnd'. 

-Changed the data_type_cd from 'C to 'LS\ 

-Changed the preload_val from T, to 'Y,N\ 

—Set the preload_desc 'Yes,No'. 

-Set optblank to V. 

-Added a colon to the end of each label. 

update web_field_edits_t 
set label='Anatomical Abnormality: 1 , 
data_type_cd = 'LS', 
preload_val = 'Y,N', 
preload_Desc = 'Yes, No' 
optblank='Y' 
where table_name = 'hearty 
and field_name = 'anatomicaUnd'; 

update web_field_edits_t 
set label='Evidence CV Disease:', 
data_type_cd = 'LS', 
preload_val = 'Y,N', 
preload_Desc = 'Yes, No' 
optblank=T 
where table_name = 'heart_t' 
and field_name = 'cv_disease_ind'; 
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update web_field_edits_t 
set label='Surgical Damage:', 
data_type_cd = 'LS', 
preload_val = 'Y,N', 
preload_Desc = 'Yes, No' 
optblank=T 
where table_name = 'heart_t' 
and field_name = 'surgical_damage_ind'; 



update web_field_Edits_t 
set label='Check if Active' 
where table_name= , employee_t , 
and field_name='active_ind'; 



Removed the "and tissue_recovery__ind = T" clause from the lk_filter column in web_field_edits_t for 
the two entries where 
table_name = 'tissue_serology_t' 
and 

field_name = 'pcr_performed_by' or 'serology^performed^by' 



Modified web_menu_t to reorder the menu entries for Organ to match the order of the nav bar items. 

1. Initial Physical Assessment 

2. Labes/Cultures 

3. Hemo 

4. Serologies 

5. Cardiac 

6. Pulmonary 

7. Operating Room 

8. ORgan Ins Supplies 

9. Specific ORgan 

10. UNOS 



Add 'reforgan.updCardiac-viewSerology' to web_action_t. Window ID is 131 - Referral Organ 
Serologies 

Add message_log_t. email to web_field_Edits_t EM,Email Address:, 75,50 

Add webonly.send_email to web_field_Edits_t C,Check to send email:, l,l,preload_val='Y' 

Change web_menu_t for logoff "javascript:confirmLogoff()" 

Add 'main. logoff to web_action_t 



Special Changes 



ConfigPkg - Modify manually 



13.3 Version 1.0.6 



R3 VErsion 1.06 Release 
10/28/2002 
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Bugtracks 



323 Provide access to non-referral specific web audit records 

407 According to Kathy/Joe, please make the following fields non-mandatory: 

412 Fix consent addendum bug 

422 The start and end dates in this area are for Hospital Agreement Ademdums and should not be 
mandatory. 

440 Error occurs when attempting to save the Tissue Team page: 

441 In Tissue Donor Record on Christopher Benoit (T01067), when we enter the onsite date and 
time of 6/1/01 11:10 it says the the onsite date/time must be greater then the referral date/time 
(which is 5/31/01 22:37). Which you can see is the case yet it will not let you proceed. 

442 when enter Tissue Referral Coordinator or Organ Referral Coordinator it will not save both as 
separate people, it will either mirror or not save. 

444 Need "cm" (centimeters) entered after each lung measurement field 

445 Kidney Anatomy fields need to accept decimal points (any size/lengths fileds 

446 Kidneys - Hard/Soft fields cannot be mandatory for the associate with Aortic and Arterial 
Plaque. If either Plaque is YES then need to complete, if plaque is NO then will not have an answer for 
Hard/soft. 

447 Post Recovery Notified. Date/time cannot be madatory for some of these may be N/A. This 
was originally intended to be a select box of which staff was notified and multiple could be selected yet 
the change was put on hold since it was close to release whwn completed. So until we can change, 
need to not make dates mandatory 

450 PCR and Serology PERFORMED BY text needs to be changed to DRAWN BY 

452 Tissue reconstruction - when save names, it adds names to other reconstructed tissues. 

453 Post serologies were added in error, then deleted and when attempted to enter Pre serology 
results, it would not allow and sent an error to the web master 

461 Recipient address, city, state, zip does not retain when "save" screen 

463 Tissue DOnor Number and Processor Number are in Database on some Tissue donors yet do 
not show on referral search list. 

464 Is there a way that these searchs can be for a time period instead of a single day. Date Range 
(to or from) or like OTIS was could enter just the year or month and year and get a list. 

467 For months on list it currently only goes from 1-99 and we need triple digit numbers 1-999. 

Thanks - many kidney recipients wait over 100 months 

469 Following error occurs trying to edit a Tissue Serology Detail record: 

475 Import Issues 



Packages 



AuditPkg 
ConsentPkg 
ConsentDataPkg 
Field 

ImpExpPkg 
Query 

RecipientPkg 

RefBasicPkg 

RefKidneyPkg 

RefMainPkg 

RefTissuePkg 

RefTissueSeroPkg 

RefUtilPkg 
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Static HTML 



formValidations.js 



Database Changes 



Changed the following columns in renal_detaiLt from number(3,0) to number(4,2): 
length 
width 

artery_distance 

cuffljength 

cuffl_diameter 

cuff3Jength 

cuff3_dia meter 

veins_distance 

vcljength 

vcl_diameter 

vc2Jength 

vc2_diameter 

vc3_length 

vc3_dia meter 

ureterljength 

ureter2_length 

ureter3Jength 

cuff2_length 

cuff2_diameter 



Changed the web_field_edits_t entries for the above fields as follows: 
—changed data_type_cd from 'N' to 'FN' 
—changed maxjength and colsize from 3 to 5 
—entered 0 for min 
—entered 99.99 for max 



Add ucase column to web_field_edits_t 



Modified the web_field_edits_t entries where table_name = 'pulmona^data^' and field_name in 
aortic_knob_width 
diaphragm_width 
leftjungjen 
rightjungjen 
ch est_ci rc J a nd m a rk 

—For the first four (width and length fields) inserted ""(cm)"" just before the : in the label. 
—Additionally, inserted " M <br>"" in the labels for rightjungjen and chest_circjandmark to make 
window fit inside 800 pixels." 



Modified the web_field_edits_t entry for table_name = YenaLdetaiLanatomy^' and field_name = 
'answerjnd' 

(added code to the onclick event) 



updated web_field_edits_t: 
transplant_t.months_onJist - Set max to 999 
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Updated label for web_field_edits_t records: 
tissue_serology_t.pcr_performed_by 
tissue_serology_t.serology_performed_by 



web_field_Edits_t 
Add webonly.referral_dt_end 



web_field_edits_t 

Change hospital_t.eyebank_agreement_dttm and eyebank_agreement_expire_dttm labels and add 
the word ""Hospital"" in front. 



web_field_edits_t 
- Update all rows for web_audit_trail_t 



window_t 
- Add window for Audit Trail 



web_action_t 

- Add audit.searchForm, searchResultsJastPage^extPage^reviousPage^rstPage^iewAuditXML 



web_menu_t 
- Add Audit Data after Help Window maintenance 



profile_windowJ: 
- Add window 189 to profile number 1 (Admin) 



In the Renal Anatomy lookup table: 
inactivated the entries labeled Hard/Soft 1 and Hard/Soft 2 
(in fact, these can and should be deleted from prod as they were dev values only) 



In the Renal Anatomy lookup table: 
set the Hard/Soft indicator (val2) to Y for Aortic Plaque and Arterial Plaque. 



Update web_field_Edits_t for certain filters to uppercase 



Special Changes 



ConfigPkg 
In ConfigPkg, 

the value for lk_kidneyRight was missing a right parenthesis 

that was causing the right kidney to be misidentified as a pancreas. 
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13.3.1 Version 1.0.6.1 



R3 VErsion 1.061 Release 
10/30/2002 



Bugtracks 



BT 428 
BT 424 

Packages 

RefLabPkg 
RefBasicPkg 

Static HTML 
None 

Database Changes 

Add field to CULTURE J*EPORTTOJDETAIL_T, HOSPITAL_ID 
Added Foreign Key constraint to HOSPITAL_T 

Add field IMPORT_OPO_ID to referral_t 

Also add two web_field_edits_t entries to add the corresponding values. 
Special Changes 



13.3.2 Version 1.0.6.2 



R3 VErsion 1.062 Release (LOPA and MORA) 
11/8/2002 



Bugtracks 



BT 491 - Two problems with Med/Social Questionnaire in Call Center: 

BT 497 - Change "Tech" to be LOPA Staff, Limit Roles, On adding Lopa Staff Limit roles 



Packages 
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MedStaffPkg 



Static HTML 



None 



Database Changes 



—Made the following web_field_edits_t changes: 

1) Modified entry where table_name = 'referraLpersonnel_t' and field_name = 
' I k_ro I ej d_h os p_staff . 

Added "and lk_val2= , H ,n to the filter. 

2) Added an entry for table_name = YeferraLpersonneLt' and field_name = 'lk_jole_id_hosp_or'. 
Identical to the record in #1 above except that the Ik_val2 filter is for 'HO'. 

3) Modified entry where table_name = 'lk_role_id' and field_name = 'lk_role_id\ 
Modified the two PRELOAD fields. 

Changed the description for 'O' from 'OR Room' to 'OPO Staff; 
added following items: 
HO - Hospital OR Staff 
H - Hospital Staff. 



Special Changes 



Update version number in ConfigPkg to 1.062 



13.4 Version 1.0.7 

R3 VErsion 1.062 Release (LOPA and MORA) 
11/8/2002 



Bugtracks 



BT 237: Uppercase 

BT 248: Deletion of action log items 

BT 253: staff Letter 

BT 396: add unos id to serach criteria 

BT 398: numbering subquestions 

BT455: 

BT 456: Gray out not recovered fields 
BT 457: Medication 

BT 460: does not refer back to recipient 

BT 471: missing fields for blood products 

BT 472: age based ruleouts 

BT 476: error in sort 

BT 479: 5.0 browser delete 

BT 482: age unit issue 

BT 486: distended 

BT 487: death dttm javascript 
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BT 488: dont allow save of medications until page saved 

BT 493: delete med social 

BT 514: tick mark in person last name 

BT 332: Med/soc versioning 



Packages 



ActionlogPkg (248) 
AuditPkg (237) 
Field (237) 
ConfigPkg (237) 
RefBasicPkg (237) 
Letterpkg (253) 
RefMainPkg (396) 
MedSocPkg (398) 
ConsentDataPkg (455) 

ConfigPkg, RefUtilPkg, RefHeartPkg, RefLungPkg, RefLiverPkg, ReflntestinePkg, RefKidneyPkg, and 

RefPancreasPkg (456) 

RecipientPkg (460) 

RefOrganPkg (471) 

RefUtilPkg (472) 

CallCtrPkg (476) 

ConsentPkg 

ContactPkg 

ImpExpPkg 

LetterPkg 

RefMainPkg 

SysMsgPkg 

CallCtrPkg and RefBasicPkg. (482) 

-Modified ReflnitPhysPkg (486) 

RefOrganPkg and MedStaffPkg. (488) 

-Modified MedSocPkg, CallCtrPkg, and RefBasicPkg. (493) 

MedStaffPkg (514) 

MedSocPkg 

QuestionPkg - Change question form logic 

WebPkg - Add function to enable disabled form elements 

SysMsgPkg - (332) 



Static HTML 



None 



Database Changes 



for 237: 

1. Add ucase column to web_field_edits_t with default Y 

2. Update web_field_Edits for certain filters to uppercase 

for 456: 

—Modified all web_field_edits_t entries where field_name = 'lk_disposition' and data_type_cd = 'LS'. 
Added the following code to the onClick and onKeytlp events for all entries: checkRecoveredQ; 



Made the following columns in the following tables nullable: 
HEART_T 
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anatomical_ind 

su rg i ca Ld a m age_i nd 

cv_diseasejnd 

LUNG_T 

anatomicaLind 
surgicaLdamageJnd 

LIVERJT 

abnormalityjnd 

surgicaLdamageJnd 

capsule_torn_ind 

hemotoma_ind 

vessels_sent_ind 

gall_blder_incised_ind 

galLblder_f!ushed_ind 

rightjiepaticjnd 

backtable_flush_ind 

biopsy_ind 

slide_sent_withjiver_ind 

INTESTINES 
anatomicaLind 
surgicaLdamageJnd 

PANCREAS_T 
wholejnd 
celiac 

spleen_attached 

portaLvein 

anatomicaLind 

anatomicaLcmmt 

surgicaLdamageJnd 

RENALJT 

warmjschemic 
insitu_flush 
flush_backtable 
sent_enblocJnd 



-Added the following column to RENAL_DETAIL_T: 
REASON_NOT_RECOVERED -- varchar2(100), nullable 

—Added a web_field_edits_t entry for table_name = YenaLdetaiLt' and field_name = 
Yeason_not_recovered' 



For 457: 



Modified the webjield_editsj: entries where field_name = 'Ik^medication' and table_name = 
'medication_administered_t' OR 'cardiac^medications^'. Removed the JavaScript code from the 
onClick event and moved it instead to both the onClick and onKeyllp events. 

BT471: 

-Altered intraoperative_mang_t (Kevin has the script that must be run in order to effect these 
changes): 
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1) Changed the datatype of the following columns to NUMBER: blood_product_l, blood_product_2, 
crystalloids_type 

2) Changed the datatype of the following columns to NUMBER(7,2): blood_prodl_volume, 
blood_prod2_volume, crystalloid_volume 

—Modified web_field_edits_t. Changed entries for records where table_name = 
'intraoperative_mang_t' and field_name in ( , blood_product_l , /blood_product_2 , / , crystalloids_type , / 
, blood_prodl_volume'/blood_prod2_volume , / 
'crystalloid_volume'). 

486: 

-Modified web_field_edits_t entry for table_name = 'gastrointestinaLt' and field_name = 
'distentedjnd' 

487: 

In web_field_edits_t / removed code from the onClick event where table_name = 'referral J:' and 
field_name = 'death_dttm'. 

493: —Two new actions will need to be added to the web action table: callctr.delHistory and 
refbasic.delHistory 

332: alter table question J: add (active_start_dttm date, active_end_dttm date, old_question_id 
number); 

alter table subquestion J: add (active_start_dttm date, active_end_dttm date, 
old_questionJd_subnumber number); 

update questionj 

set active_start_dttm = to_date('01/01/1990 00:00:00ymm/dd/yyyy hh24:mi:ss'); 

update question_t 

set active_end_dttm = update_dttm 
where isactivejnd 1= V; 

update subquestion_t 
set active_start_dttm = to_date('01/01/1990 00:00:00ymm/dd/yyyy hh24:mi:ss'); 

update subquestionj 

set active_end_dttm = update_dttm 
where isactivejnd != T; 

alter table question_t drop (isactivejnd); 

alter table subquestionj: drop (isactivejnd); 

webjield_editsj 

web_actionJ - add new action for question. 



Special Changes 



Update version number in ConfigPkg to 1.07 
-Modified layers.js. 
-Modified formValidations.js 
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Uppercase Process 



Run the following 3 scripts logged in as R3DBA. The output should be saved for an audit trail. 

1. create_table.sql - This will examine all table in the R3DBA schema and create 

a TEMP_BT237JJPPER table containing all the columns that will be converted 
to uppercase. 

2. do_upper.sql - This script actually performs the uppercase conversions based on 

the information in the TEMP_BT237_UPPER table. As each column is updated, the 
information is updated in the TEMP_BT237_UPPER table so this serves as an 
audit trail of what data was or was not converted. 

3. update_web_field_edits_sql - This script updates the UCASE flag in web_Field_edits_t. 

All rows are set to UCASE='Y' and then the exceptions are blanked out. 



13.4,1 Version 1,0,7,1 

R3 Version 1.071 Release (LOPA) 
11/22/2002 

Made change manually in PROD 
Bugtracks 

BT 519: OR Mgmt — Blood product 
Packages 

RefOrganPkg (519) 

Static HTML 
None 

Database Changes 



None 



Special Changes 



None 



Uppercase Process 
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None 



13.5 Version 1.0.8 

R3 Version 1.08 Release (LOPA) 
12/05/02 



Bugtracks 



304, 505, 523, 416, 418, 498, 516, 448, 470, 436, 503, 521, 509, 519, 522, 
580, 506, 517, 524, 518, 520 



Packages 



ConsentDataPkg (304,505,523) 
RefMainPkg (416,498,516) 
Correspondence (416) 
refTissue (448) 
CallCtrPkg(470,498) 
DonorPkg (436) 
RefUtilPkg (498, 503, 521) 
RefOrganPkg (498,509,519) 
MedStaffPkg (498, 522) 
RefcardioPulmPkg (580) 
RefLabPkg (506) 
ActionlogPjg (517, 524) 
QuestionPkg (518) 
QueryPkg (520) 
RecipientPkg (520) 
main procedure (516) 
Error (516) 
ConfigPkg (516) 
LetterPkg (516) 
Debug (516) 
Query (516) 

(all in packages. sql - run as R3APP) 



Static HTML 



formValidations.js 

bloodvol.js 

formcheck.js 

Database Changes 



Run the following scripts : (all as R3DBA) 
BT494 Script 1 
BT 494 Script 2 
datachanges.sql 

ref e r ra I le tt e rs_t .sql 

ref e r ra l_lettes_t_sy n . sq I 



Special Changes 
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run import of web_field_edits_1205.dmp 

Go through the management console and set the types for consent items (organ or tissue) 



Order of Operations: 



1. Turn off web server. 

2. Run Backup 

3. Move static content 

4. Run packages. sql (as R3APP) 

5. Truncate web_field_Edits_t 

6. run import of web_field_edits_1205.dmp 

7. Run BT 494 script 1 

8. run bt 494 script 2 

9. run datachanges.sql 

10. refjetters_tsql 

11. referral_letters_t_syn.sql 



Test by checking various BT's, add a new referral through call center and referral basics 



13.6 Version 1.0.9 

R3 Version 1.09 Release (LOPA) 
12/16/02 



Bugtracks 



438 - Move all OPO specific coding to ConfigPkg 

534 - Convert 209,000 registry records from old OTIS system and import into R3 

535 - Medications no longer appearing on OR Management 

536 - "C: Total Volume of Crystalloids Infused in the Last 1 Hour" text change 

538 - Active/Inactive code for OPO/Organizations 

539 - Add a comment section to Tissue Main under the tissues recovered. 

540 - Add "order by" to the query for Tissue Team 

541 - Tissue Physical Assessment - Add field "Pathology Sample Obtained" with "Y/IM" answer and 
comment area. 

542 - Call Center - Entering birthdate of 12/25/1925 comes up with an age of 77, not 76 
552 - Correct eye ruleout for Age 



Procedures 



Download 

Main 

PL 

(all in procedures. sql - run as R3APP) 
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Packages 

ActionLogPkg 

AuditPkg 

CallCtrPkg 

ConfigPkg 

ConsentDataPkg 

ConsentPkg 

ContactPkg 

CorrespondencePkg 

Debug 

DonorPkg 

Error 

EyeBankPkg 

FeedbackPkg 

Field 

FileAPI 

HelpPkg 

HospitalPkg 

ImpExpPkg 

LetterPkg 

LookupPkg 

MainPkg 

MedSocPkg 

MedStaffPkg 

MessageLogPkg 

OPOOrgPkg 

ProfilePkg 

Query 

QuestionPkg 

RecipientPkg 

RefBasicPkg 

RefCardioPulmPkg 

RefHeartPkg 

ReflnitPhysPkg 

ReflnstrumentPkg 

ReflntestinePkg 

RefKidneyPkg 

RefLabPkg 

RefLiverPkg 

RefLungPkg 

RefMainPkg 

RefOrganPkg 

RefPancreasPkg 

RefRecipPkg 

RefSeroPkg 

RefTissuePkg 

RefTissueSeroPkg 

RefTissueTrackPkg 

RefUtilPkg 

RegLinkPkg 

Req 

RulePkg 

SecPkg 

Ses 

SysMsgPkg 

TestPkg 

UserPkg 



Page 85 



February 3, 2003 



R3 - Architecture 



JMCS 



WebActionPkg 

WebMenuPkg 

WebPkg 

XML 

Xpath 

(all in packages_r3app.sql - run as R3APP) 



Packages (R3DBA) 



ImpExpPkg 

(all in packages_r3dba.sql - run as R3DBA) 



Static HTML 



layers.js 
r3.css 

Delete lopa.css 



Database Changes 



Run the following scripts : (all as R3DBA) 

1. registry_alters.sql - This will change the several columns in registry and snapshot tables. 

This needs to be done before the import file is loaded. 

2. data changes. sql - Apply DML and DDL changes 



Special Changes 



run import of web_field_edits_1216.dmp 



Order of Operations 



1. Turn off web server. 

2. Run Backup 

3. Move static content 

4. Run Migrate.bat r3prod > migrate_r3prod.log 2>&1 

registry_alters.sql 

datachanges.sql 

import web_field_edits_t 

procedures. sql 

packages_r3app.sql 

packages_r3dba.sql 

5. Manually update new COnfigPkg to match environment 

6. Restart webserver 



Testing 



1. Test by checking various BT's, add a new referral through call center and referral basics 
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Post Migration 

Load the r3convert.csv and import this into the database using the web interface. 



13.7 Version 1.1.0 



R3 Version 1.10 Release (LOPA) 
12/23/02 



Bugtracks 



502 - In the recipient info, date of birth is not always known. 

543 - Renal Data needs to be a seperate screen from the kidney anatomy 

550 - We need the ability to see the screening criteria that is selected to prove the outcome. 

551 - When they select "Pending" as an outcome, it reverts back to referral each time they open it. 

553 - Hospital entry Development Coordinator - can "Not Applicable" be added to this select list? 

554 - Approacher and Discussed by select lists need to contain clinical and Acadian Staff ONLY 

555 - Tissue Referral Coordinator - select box needs to be tissue staff Organ Referral Coordinator - 
select box needs to be organ staff 

557 - Staff Name select boxes need to be Tissue staff only. 

558 - If a user is inactive should they be appearing in a select list? 

559 - On the recipient list, there are some recipients that are attached to referrals that dont have a 
generatead referral id. 

560 - Serology & PCR performed by select boxes need to be clinical staff only. 

561 - The first field on the screen looks for an OPO_T entry that is an "entry" OPO type. 

562 - Total plasma volume is calculated by body weight in lbs instead of kilograms. 

564 - When you put "no" for eyes recovered and hit save, it stays blank. 

565 - Please add a filter for "Pending" referrals to the filter list. This should show only those referrals 
that are pending. 

566 - On the Tissue serology page, we need to add two new fields. One is 

LK_SEROLOGY_DRAWN_BY_TYPE, and LK_PCR_DRAW_BY_TYPE. These will be drop downs next to the 
serology drawn by userid dropdown and the per drawn by userid dropdowns. 



Procedures 



N/A 



Packages (r3app) 



(all in packages_r3app.sql - run as R3APP) 

CallCtrPkg 

ConfigPkg 

HospitalPkg 

OPOOrgPkg 

RecipientPkg 

RefKidneyPkg 

RefMainPkg 

RefTissuePkg 
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RefTissueSeroPkg 
RefUtilPkg 



Packages (r3dba) 



N/A 



Static HTML 



formValidations.js 



Database Changes 



Run the following scripts : (all as R3DBA) 

1. data changes. sql - Apply DML and DDL changes 



Special Changes 



run import of web_field_edits_t.dmp 



Order of Operations 



1. Turn off web server. 

2. Run Backup 

3. Move static content 

4. Modify DataChanges.sql for starting point of vali_id for lookup_values_t inserts 

4. Run Migrate.bat r3prod > migrate_r3prod.log 2>&1 

datachanges.sql 

import web_field_edits_t 

procedures.sql 

packages_r3app.sql 

packages_/3dba.sql 

5. Manually update new COnfigPkg to match environment 

6. Restart webserver 



Testing 



1. Test by checking various BT's, add a new referral through call center and referral basics 



13.8 Version 1.1.1 

R3 Version 1.10 Release (LOPA) 
12/23/02 
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Bugtracks 

502 - In the recipient info, date of birth is not always known. 

543 - Renal Data needs to be a seperate screen from the kidney anatomy 

550 - We need the ability to see the screening criteria that is selected to prove the outcome. 

551 - When they select "Pending" as an outcome, it reverts back to referral each time they open it. 

553 - Hospital entry Development Coordinator - can "Not Applicable" be added to this select list? 

554 - Approacher and Discussed by select lists need to contain clinical and Acadian Staff ONLY 

555 - Tissue Referral Coordinator - select box needs to be tissue staff Organ Referral Coordinator - 
select box needs to be organ staff 

557 - Staff Name select boxes need to be Tissue staff only. 

558 - If a user is inactive should they be appearing in a select list? 

559 - On the recipient list, there are some recipients that are attached to referrals that dont have a 
generatead referral id. 

560 - Serology & PCR performed by select boxes need to be clinical staff only. 

561 - The first field on the screen looks for an OPO_T entry that is an "entry" OPO type. 

562 - Total plasma volume is calculated by body weight in lbs instead of kilograms. 

564 - When you put "no" for eyes recovered and hit save, it stays blank. 

565 - Please add a filter for "Pending" referrals to the filter list. This should show only those referrals 
that are pending. 

566 - On the Tissue serology page, we need to add two new fields. One is 

LK_SEROLOGY_DRAWN_BY_TYPE, and LK_PCR_DRAW_BY_TYPE. These will be drop downs next to the 
serology drawn by userid dropdown and the per drawn by userid dropdowns. 



Procedures 



N/A 



Packages (r3app) 



(all in packages_r3app.sql - run as R3APP) 

CallCtrPkg 

ConfigPkg 

HospitalPkg 

OPOOrgPkg 

RecipientPkg 

RefKidneyPkg 

RefMainPkg 

RefTissuePkg 

RefTissueSeroPkg 

RefUtilPkg 



Packages (r3dba) 
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N/A 



Static HTML 



formValidations.js 



Database Changes 



Run the following scripts : (all as R3DBA) 

1. data changes.sql - Apply DML and DDL changes 



Special Changes 



run import of webjield_edits_tdmp 



Order of Operations 



1. Turn off web server. 

2. Run Backup 

3. Move static content 

4. Modify DataChanges.sql for starting point of valijd for lookup_values_t inserts 

4. Run Migrate.bat r3prod > migrate_r3prod.log 2>&1 

datachanges.sql 

import web_field_edits_t 

procedures. sql 

packages_r3app.sql 

packages_r3dba.sql 

5. Manually update new COnfigPkg to match environment 

6. Restart webserver 



Testing 



1. Test by checking various BT's, add a new referral through call center and referral basics 
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13.9 Version 1.1.2 

R3 Version 1.12 Release (LOPA) 
01/27/03 02:00 CST 



Bugtracks 

575 - Remove mandatory fields from consent screen 

578 - Add Save NEw function for letters 

579 - Add "Organ" to blood culture drop down 

580 - Add tissue ruleout reason to 24/72 hour search 

Procedures 
N/A 

Packages (r3app) 

(all in packages_r3app.sql - run as R3APP) 

CallCtrPkg 

ConsentDataPkg 

LetterPkg 

RefTissuePkg 

Packages (r3dba) 
N/A 

Static HTML 
formValidations.js 

Database Changes 

Run the following scripts : (all as R3DBA) 

1. data changes. sql - Apply DML and DDL changes 

Special Changes 

run import of web_field_edits_t.dmp 
Order of Operations 
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1. Turn off web server. 

2. Run Backup 

3. Move static content 

4. Run Migrate.bat r3prod > migrate_r3prod.log 2>&1 

datachanges.sql 

import web_field_edits_t 

procedures. sql 

packages_r3app.sql 

packages_r3dba.sql 

5. Manually update new COnfigPkg to match environment and 1.12 release number 

6. Restart webserver 



Testing 

1. Test by checking various BT's, add a new referral through call center and referral basics 
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14 Security/Auditing 



14.1 R3 A p plication Securit y 

Access to the R3 application in the development, test and production environments is handled through 
the application itself. 

• User management. An R3 system administrator establishes and maintains information about 
individual users. A user must be defined to R3, and assigned a specific security profile, before R3 
will allow access. Once established, users are permitted and required to change their passwords 
periodically. A system administrator may reset a user's password if required (and then the user 
must change it). 

• Security profile management. A system administrator also defines named security profiles, 
which defines two key application access characteristics: the individual screens (web pages) that 
users assigned that security profile are allowed to see; and what function (read-only; read and 
add only; read, add, and update; and read, add, update and delete) users can perform to the 
content of that individual screen. These security profiles are then assigned to individual users. 

The individual user ID assigned determines the security profile, which is checked before entry into 
every screen. Users not permitted access to certain parts of the application instead simply see a 
screen with an access denied message. Users with restricted functionality (e.g., read-only) see the 
same screen, but the contents may be display-only without any add, update or delete buttons 
displayed. Users allowed to add or update, but not delete, see the same screens but without the 
delete buttons. 

One other aspect of R3 security lies in the means used to grant individuals at other institutions 
(eyebanks and hospitals and transplant centers) access to basic and clinical donor and organ 
information for eye and organ suitability and organ matching for transplants. 

• Eyebank access. There is a facility in R3 to limit certain users to show referrals related to a 
particular eyebank *only*. This is done via the organization the user is tied to. If the user is tied 
to an organization that has a specific eyebank associated to it (under the Organization details 
panel in the management console), then when that user logs in, the system will only show those 
referrals for their eyebank. Currently there are three eyebank organizations defined in the system 
- one for Northwest Lions Eye bank, one for Baton Rouge eye bank, and the other for Southern 
eyebank. 



• Hospital and transplant center access. R3 permits read-only outside access to basic and 

clinical donor information to hospitals and transplant centers. An R3 system administrator, as part 
of setting up the hospital information, records the UNOS contact's name and email address. When 
an organ donor is in process, a LOPA recovery coordinator uses a specific R3 screen to log into the 
Unet system to notify UNOS of the potential organ(s) availability and begin the placement process. 
The same screen also allows selection of a hospital or transplant center to whom the organ(s) will 
be offered. If a UNOS contact has been defined, that individual's name and email address will be 
displayed and used, or a different email address can be entered. R3 generates an email to that 
recipient, which contains an R3 login user ID and a password, and a link pointing to the R3 web 
site but using a security key pointing to a single referral. The link, and its embedded security key, 
expires after 24 hours. 



15 R3 Auditing Trail Record 



15.1 Introduction 



As part of good system practice - and as support for HIPAA and FDA regulations - all of the actions 
that a user does in the system are logged. The idea of "auditing" what a user does - regardless of 
what it is - enables management to keep a better track of who is changing and viewing the data. 

There are two major philosophies of auditing. The first says that all the system takes the most 
straightforward tact into recording auditing data, and that reporting off of this data will be more 
challenging. The second philosophy says that the auditing data is recorded in such a way that make it 
easy to report, but more challenging to store. 

Because the auditing reporting requirements were nebulous at the time of the system design, it was 
decided to go with an approach where the auditing information was easily recorded. The reporting 
requirements - when they come - will be dealt with when they arrive. TO that end, everything 
possible is recorded about any web action done by the user. 

The W E B_AU DIT_TRAI L__T table contains all of the audit data in the system. Any web request made to 
the system is logged into this table. 



15.2 Data Stored 



The W E B_AU DIT_TRAI L_T table has the following data elements 

AUDIT_ID NOT NULL NUMBER 

AUD I T_DATE_T I ME NOT NULL DATE 

IP_ADDRESS NOT NULL CHAR (15) 
AUDIT_DATA OBJECT 
USER_NM VARCHAR2 ( 15 ) 

ACTION VARCHAR2(50) 
BROWSER VARCHAR2 (255) 

CRE ATE_US E R_I D VARCHAR2 ( 8 ) 

CREATE_DTTM DATE 
UPDATE_USER_ID VARCHAR2 ( 8 ) 

UPDATE_DTTM DATE 

The following is an explanation of each field: 

AUDITJD: This field is a sequential number that serves as the primary identified for the audit record. 
AU DIT_D ATE_TI M E : The date/time for the audit action being recorded. 
IP_ADDRESS: This is the IP address where the client request came from. 

AUDIT_DATA: This is an XML document which lists ail the fields being sent to the server to record. See 
the next section for further details. 

USER_NM: The logged on user name that has sent the request for the audit auction. 



ACTION: The "web action" that relates to this request. All the windows in the system are related to a 
"web action", which describes what is being done on that screen. 
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BROWSER: The type of browser reported by the browser that the user is using. This often includes 
operating system and version details as well. 

CREATE_USER_ID/CREATE_DTTM: The userid that created the audit record and the date/time of 
creation. This will almost always be the same as the USER_NM and the AUDIT_DATE_TIME. 

UPDATE JJSER_ID/UPDATE_DTTM: On the rare case when the data in this table is manipulated by the 
system or by scripts, this will list the userid doing the updating as well as the date time the update 
happened. 



15.3 Technical Details 



15.3.1 XML 



XML is a way of cataloguing data by type, utilizing user-specified fields. In this case, all of the data 
submitted to the web is saved in an XML document (an example which is in the next section). By 
storing it in XML, we can compare and contrast similar fields, and provide indexing capabilities on 
certain data elements. IF we had stored the audit data as text, it would have been much more difficult 
-if not impossible - to pull the data as needed to do reporting. 



15.3.2 Indexing 

Oracle has special facilities to add database indexes to XML data types. The way we are indexing the 
XML (specifically, by referral id, which is by far the most common view of the data) is to utilize what is 
known as context indexes. 



15.4 Example _ ^V. 

An example XML Audit record might be: 

<parameters> 
<action>callctr.viewMain</action> 

<admission_cmmt>DX: INTRACEBRAL BLEED W/ QUESTIONAL AV MALFORMATION NO 
OTHER PERTINENT HX PT HAS GLASCOW OF 2 AND HAS BEEN PRONOUNCED BY 1 
DOCTOR AS BRAIN DEAD HE IS WAITING FOR NEUROLOGIST</admission_cmmt> 

<admission_dttm>01/ 19/2003 12:00</admission_dttm> 

<birth_dt>08/26/1947</birth_dt> 

<contact_first_nm>CAROLYN</contact_first_nm> 

<contactJd>84394</contacMd> 

<contactJast_nm>GRIFFIN</contactJast_nm> 

<contact_phone>(985) 649-8588</contact_phone> 

<eye_bank_agreement>SEB</eye_bank_agreement> 

<first_nm>GEORGANN</nrst_nm> 

<gender_cd>F</gender_cd> 
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<height_ft>5</height_ft> 
<heightjn>7</height_in> 

< hospita Lid > LASS </hospital_id > 
<hospitaLstate>LA</hospitaLstate> 

< i n_reg istryjnd > N </i n_reg istry_i nd > 
<last_nm>FERGUSON</last_nm> 

<lk_agreement_type>Organ and Tissue</lk_agreement_type> 

<lk_hospitaLunit>652</lk_hospitaLunit> 

<lk_race>910</lk_race> 

<lk_tit!e>1382</lk_title> 

<on_vent_ind>Y</on_vent_ind> 

<opo_num>139</opo_num> 

<referraLdttm>01/20/2003 ll:17</referraLdttm> 

< refid >267019</refid > 

<taken_by_phone_ind>Y</taken_by_phone„ind> 
<w_dspLayout>Normal</w_dspLayout> 
<weight>130</weight> 
</parameters> 



The data here indicates all of the fields on the screen as submitted at the time of the audit trail date. 
By tracking multiple actions, one can tell what information has been changed on a record and by 
whom. 



15.5 Table level auditing 



The other way data is audited is by utilizing what is known as Oracle "triggers". These triggers are put 
on every table, both a "create" trigger and "update" trigger. The "create" trigger automatically 
populates the CREATE_USER_ID and CREATE_DTTM data for each row - the user inserting the data 
cannot override this without SYS DBA access. Similarly, the UPDATE_USER_ID and UPDATE_DTTM 
data for each row is populated by the "update' trigger. 



Page 96 



February 3, 2003 



16 Appendix 1 



16.1 GANTT Chart 



ID 


0 
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B | M | E 
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15 


</ 


Requirements definition 








22 
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33 




Build replacement user interface 














00% 


217 


>f 


Identify database cleanup/conversion 
requirements 
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V 


Establish newapp &DB environment 














% 
X)% 

100% 


239 


V 


Conduct system test 




IV 


245 




Conduct Integration test 








252 




Complete new app training 


y 




261 




Conduct user acceptance test 






268 


<s 


Prepare documentation 












281 




Implemant In production 








288 




Provide 60-day post- implementation suppport 








00% 



16.2 Task List 



The following is a breakdown of tasks up to and including the deployment of Release 1.0 of R3. 



Project startup and logistics 


18 days 


2/20/02 


3/15/02 


100% 




Schedule initial requirements overview 


1 day 


2/26/02 


2/26/02 


100% 




Schedule detailed work sessions 


1 day 


2/26/02 


2/26/02 


100% 




Get OTIS/AL and DB export 


1 day 


2/20/02 


2/20/02 


100% 




Get OTIS/AL logins 


1 day 


2/20/02 


2/20/02 


100% 




Set status reporting details 


1 day 


2/26/02 


2/26/02 


100% 




Set requirements doc & review details 


1 day 


2/25/02 


2/25/02 


100% 




Confirm requirements gathering approach 


1 day 


3/5/02 


3/5/02 


100% 




Schedule OTIS, AL, OTIS (incl mgmt 












console) walk thru 


1 day 


2/26/02 


2/26/02 


100% 




Agree on issue, question, bug tracking 












approach and tool 


1 day 


2/26/02 


2/26/02 


100% 




Agree on coordination approach and 












logistics with DMG 


2 days 


3/5/02 


3/6/02 


100% 




Obtain and install SQL/Navigator on 












JMCS developer workstations 


5 days 


3/4/02 


3/8/02 


100% 




Set up LOPA folders on JMCS server 


1 day 


2/25/02 


2/25/02 


100% 




Install SQL/Navigator on LOPA 












workstation 


1 day 


3/15/02 


3/15/02 


100% 




Requirements definition 


24 days 


2/27/02 


4/1/02 


100% 




Vision and overview 


1 day 


2/27/02 


2/27/02 


100% 




Get Ans Line, OTIS, full OTIS mgmt 












console walk thru 


3 days 


3/5/02 


3/7/02 


100% 


9 


Initial requirements 


2 days 


3/5/02 


3/6/02 


100% 


2 


Detail requirements 


7 days 


3/14/02 


3/22/02 


100% 


18,3 


Prepare requirements documentation 


5 days 


3/25/02 


3/29/02 


100% 


19,17 
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Review requirements documnentation 
Analyze current database, procedures and 
environment 

Install 9i/9iAS on JMCS Solaris server 

Import current OTIS database and stored 

procedures 

Analyze current tables and contents 
Develop recommendations for database 
table changes 

talk to DMG about database issues 
Analyze current LOPA database server 
environment 

Complete initial database design 
Communicate replacement database 
design to DMG 

Revise database design based on user 
feedback 

Send revised database design to DMG 

Build replacement user interface 

Obtain LOPA graphics and other web 
preferences 

Develop initial look & feel prototype 
Review L&F prototype with LOPA, 
Acadian 

Develop initial Ul design 

Map requirements to Ul pages 

Develop common stored procedures 

Develop Screen Design/Prototype 

Review Ul prototype with LOPA 

Review Ul prototype with Acadian 

Review final Ul with LOPA 

Explore setting up automatic paging in 

OTIS with Acadian and Lopa 
Develop & unit test full Ul and stored 
procedures 
Lance Tasks 

LOGIN Page 

Security Privacy/Page 

Main View Page 

Main Answerline Page 

Management Console Main 

Messaging Maintenance 

System Lookup list 

Maintain Lookup Items 

Maintain Lookup 

List Hospitals 

List Eyebanks 

Maintain Hospital 

Maintain Eyebanks 

Main security 

List users 



1 day 


4/1/02 


Ah 102 


100% 


20 
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37 
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100% 




Lance 


51 days 
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38 
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Mo.Kir 
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100% 




Lance 


1 day 


6/24/02 


6/24/02 


100% 




Lance 


1 day 


6/17/02 


6/17/02 


100% 




Lance 


1 day 


6/18/02 


6/18/02 


100% 




Lance 
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List User profiles 


A J., j 

1 day 


o/l 9/02 


a 1 A O/AO 

0/19/02 


4 A AO/ 

100% 




Lance 


Maintain User 


1 day 


b/20/02 


/on /no 


4 A AO/ 




Lance 


Maintain User Profiles 


1 day 


c/oh /no 
b/21/02 


c/oH /no 
O/Zl/0^ 


•i nno/ 
lUUvo 




Lance 


Assign uSer to manager 


1 day 


0/22/02 


a 1*1 a /no 
6/24/02 


4 nno/ 
100% 




Lance 


Assign user to p rofile 


1 day 


/O O /A A 

6/23/02 


/a >1 /AO 

6/24/02 


•1 A AO/ 

100% 




Lance 


Assign windows to User profiles 


1 day 


/"> /O j4 /A A 

6/24/02 


/> /a >4 /AO 

6/24/02 


4 a AO/ 

100% 




Lance 


List OPO's/Organizations 


1 day 


/ocr /A A 

6/25/02 


/a IT /A A 

6/25/02 


h nno/ 

100% 




Lance 


Maintain OPO/Organizations 


1 day 


/-% ir\/y /AA 

6/26/02 


Z? /A ^ /A A 

6/26/02 


4 A AO/ 

1 00% 




Lance 


Maintain Organization Contact 


1 day 


o/2 7/02 


e/oT/no 
o/2 7/02 


*i nno/ 
100% 




Lance 


List/View attachments 


1 day 






4 nno/ 
1 UU /o 




Lance 


Add attachment 


2 days 


o /o /no 
O/2/02 


Q/c/no 
0/0/0^ 


-i nno/ 




Lance 


Referral Search 


2 days 


c/OT/no 
O/Z / /uz 


c/oo/no 


4 nno/ 
lUUvo 




Lance 


Referral List 


1 day 


7/4 /no 

7/1 /02 


7/h /no 
7/1/02 


h nno/ 
100% 


I4y 


Lance 


Import DMV 


5 days 


6/28/02 


~T I A /AO 

7/4/02 


4 A AO/ 

100% 




Lance 


Import Registry 


3 days 


7/5/02 


7/A/AO 

7/9/02 


•1 nno/ 
1UU% 




Lance 


Add Recipient 


1 day 


7/1 7/02 


7/1 7/02 


<4 AAO/ 

1 00% 




Lance 


Add recipient organ info 


1 day 


—w 1 A C% /A A 

7/18/02 


—9 1 A C\ /A A 

7/18/02 


<4 AAO/ 

100% 


«4 CO 

153 


Lance 


Recipient Search 


1 day 


7/19/02 


7/19/02 


100% 


154 


Lance 


Recipient List 


2 days 


7/22/02 


7/23/02 


100% 


155 


Lance 


Recipien/Transplant Info 


2 days 


7/24/02 


7/25/02 


100% 


156 


Lance 


Lock Referral 


1 day 


7/15/02 


7/15/02 


100% 


157 


Lance 


Post letter(s) to referral 


1 day 


7/19/02 


7/19/02 


100% 


158 


Lance 


Generate billing tickler email(s) for organ 














donation(s) 


0.5 days 


7/24/02 


^ /O /4 /A A 

7/24/02 


4 AAO/ 

100% 


H CA 

159 


Lance 


Finish Import and Export Records 


3 days 


"7 /O yf /AO 

7/24/02 


7 /oa /no 

7/29/02 


h nno/ 
100% 


•1 cn 
IbO 


Lance 


Review Audit Trail 


1 day 


-7 IftA /A A 

7/29/02 


-7 /A A /AO 

7/30/02 


«| AAO/ 

1 00% 


161 


Lance 


Link to Crystal Enterprise 


1 day 


7/26/02 


7/26/02 


100% 


157 


Lance 


Qpipp* and oenerate letterfs^ 


4 days 


7/29/02 


8/1/02 


1 00% 


163 


Lance 


Print Function for Help Manual 


1 day 


8/2/02 


8/2/02 


100% 


164 


Lance 


Registry Search 


2 days 


8/5/02 


8/6/02 


100% 


165 


Lance 


Registry Record Update 


2 days 


8/7/02 


8/8/02 


100% 


166 


Lance 












159,163- 




Security/Testing 


5 days 
54.5 


8/7/02 


8/13/02 


100% 


166 


Lance 


Kevin's Tasks 


days 


5/23/02 


8/7/02 


100% 






Action Log 


2 days 


6/10/02 


6/11/02 


100% 




Kevin 


medical/social including additional 














explanatory text 


4 days 


r* /o O (AO 

5/23/02 


£T /A A /AO 

5/29/02 


«1 AAO/ 

100% 




Kevin 


Answerline-Basic Info 


1 day 


-7 /o /A A 

7/8/02 


-7 /a /A A 

7/9/02 


h nno/ 

1 00% 




Kevin 


Answerline-Absolute Rule out 


1 day 


-T /A / Art 

7/9/02 


"7/ .4 A /A A 

7/10/02 


4 nno/ 
100% 




Kevin 


Answerline=Other rule out 


1 day 


^ /<< a /An 

7/10/02 


-7 / j ^ /A A 

7/11/02 


4 AAO/ 

1 00% 




Kevin 


answerline-consent 


1 day 


^ I A A /AO 

7/11/02 


7/iA /A A 

7/12/02 


H AAO/ 

1 00% 




Kevin 


Anserline-Hemodilution 


2 days 


"7 /O /AO 

7/3/02 


-7 /£- /AO 

7/5/02 


4 AAO/ 

100% 




Kevin 


answerline-medical social 


3 days 


C/OO /AO 

5/23/02 


c/oo/no 
5/28/02 


4 AAO/ 
100% 




Kevin 


answerline-resolution 


1 day 


7/1 5/02 


7/15/02 


100% 




Kevin 


anserline-referral search 


1 day 


7M e/no 
771 O/02 


"7/"i e/no 


h nno/ 
100% 




Kevin 


answerline-action log 


1 day 


7/16/02 


7/17/02 


100% 




Kevin 


answerline-messsage log 


1 day 


7/17/02 


7/18/02 


100% 




Kevin 


serologies intake/output 


2 days 


7/17/02 


7/18/02 


100% 




Kevin 


Organ labs/cultures 


1 day 


7/5/02 


7/5/02 


100% 




Kevin 


Correspondence Log 


2 days 


7/15/02 


7/16/02 


100% 




Kevin 
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Donor Referral Info 2 days 

Donor Hospital Info 2 days 

hemodynamics/temp/meds 1 day 

Medical Examiner Coroner/Info 2 days 

Admission Coourse 2 days 

Blood products 2 days 

OR/OR Management 1 day 

initial physical 4 days 

Organ Instrument Supplies 2 days 

Consent Data 2 days 

Specific Organ Info 4 days 

UNOS Interface pAge 2 days 

Security/Testing 5 days 

Mo's Tasks 9 days 

Recover team info 1 day 

Tissue Tracking 1 day 

Recovered Tissue 1 day 

Tissue Operative Summary 1 day 

Instrument Reagants 1 day 

Culture Results 1 day 

Tissue Instrument Supplies 1 day 

Hemodilution 1 day 

Main R Cubed Page that has links 1 day 

Test security/Additional testing 5 days 

Integration with Crystal Reports 35 days 

Identify JMCS Server 1 day 
Install Crystal Enterprise on JMCS server 2 days 
Design and develop userid pass-through 

viaJSP/CSP 10 days 

Import Crystal Reports from DMG 2 days 

Test Links 2 days 

Test Security pass through 2 days 

Identify database cleanup/conversion 1 1 1 

requirements days 

Identify historical data for conversion 2 days 
Identify record counts and control totals to 
be used in monitoring cleanupo, deletion 

and conversion 2 days 

Reconcile data elements for conversion 25 days 

Develop, test conversion procedures 1 6 days 
Create Validation Plan for test conversion 

procedures 2 days 

145 

Establish new app & DB environment days 

Obtain LOPA server and software 20 days 

Set up DEV environment 2 days 
Develop and test DEV backup and restore 

procedures 2 days 

Set up TEST environment 2 days 
Develop and test TEST backup and 

restore procedures 2 days 

Set up PROD environment 2 days 



T IA t ZOO 

7/1 7/02 


"7 /<i o /no 

7/1 8/02 


100% 




Kevin 


~w fc /no 

7/5/02 


-7 /o /oo 

7/8/02 


<4 nno/ 

1 00% 




Kevin 


—w ic% /AO 

7/8/02 


-7 in /no 

7/8/02 


4 nno/ 

100% 




Kevin 


-j> if\ /AO 

7/9/02 


"t /«* n /no 

7/10/02 


4 nno/ 

100% 




Kevin 


7/10/02 


-r / j j /no 

7/1 1/02 


4 nno/ 

1 00% 




Kevin 


—r 1 a a /no 

7/11/02 


*7/*i o/no 

7/12/02 


4 nno/ 

100% 




Kevin 


7/9/02 


"7 /A/AO 

7/9/02 


4 nno/ 

100% 




Kevin 


—7 1 A C\ /AO 

7/19/02 


^ /o >i /no 

7/24/02 


h nno/ 

100% 




Kevin 


-r tr\ A /no 

1124102 


^ /o c /no 

7/25/02 


•i nno/ 

100% 




Kevin 


~ii**a /no 

7/24/02 


7/oc /no 

7/25/02 


4 nno/ 
100% 


4 no 
193 


Kevin 


T /o/? /no 

7/26/02 


-» /o 4 /no 

7/31/02 


«i nno/ 

100% 


a r\ a 

194 


Kevin 


ft IA /no 

8/1/02 


ft /O /ft o 

8/2/02 


1 00% 


195 


Kevin 


ft IA /AO 

8/1/02 


ft /T /ft O 

8/7/02 


<< nnn/ 

100% 


A no A no <4 ftc 

192,193,195 


Kevin 


—j /o a /no 

7/31/02 


o /<< o /no 

8/12/02 


4 nno/ 

100% 






—w /O A ZOO 

7/31/02 


•r/oi /no 

7/31/02 


«< nno/ 

100% 




Mo 


ft IA /nO 

8/1/02 


a i a /no 

8/1/02 


4 nno/ 

1 00% 


4 nn 

199 


MO 


o /o /no 

8/2/02 


ft /O /ft o 

8/2/02 


4 nno/ 

1 00% 


onn 

200 


MO 


o ic /no 

8/5/02 


o /c /no 

8/5/02 


h nno/ 

100% 


on a 

201 


ft A**. 

Mo 


o ic /no 

8/6/02 


o /e /no 
8/6/02 


4 nno/ 
100% 


ono 
202 


MO 


o it /no 

8/7/02 


o /^ /no 

8/7/02 


h nno/ 

1 00% 


ono 

203 


MO 


o /o /no 

8/8/02 


o /o /no 

8/8/02 


4 nno/ 

100% 


204 


MO 


8/9/02 


8/9/02 


100% 


205 


Mo 


8/12/02 


8/12/02 


100% 


206 


Mo 


8/1/02 


8/7/02 


100% 




Mo 


6/17/02 


8/2/02 


100% 






6/17/02 


6/17/02 


100% 




Jeff.Mo 


fi/1 7/02 

\JI 1 f IXJsL 


6/1 8/02 

\J/ 1 <J/ V/ 


1 00% 




DMG Mo 


7/12/02 


7/25/02 


100% 


212 


DMG 


7/26/02 


7/29/02 


100% 


213 


Mo 


7/30/02 


7/31/02 


100% 


214 


Mo 


8/1/02 


8/2/02 


100% 


215 


Mo 


2/20/02 


7/24/02 


100% 










1 nn°A 

1UU /o 


I IO 




4/4/02 


4/5/02 


100% 




LOPA 


2/20/02 


3/26/02 


100% 




LOPA 


7/1/02 


7/22/02 


100% 




Mo.Lance 


7/22/02 


7/24/02 


100% 


221 


LOPA.Mo 




Q/1 0/02 








5/20/02 


6/14/02 


100% 






4/1/02 


4/2/02 


100% 


23 




4/3/02 


4/4/02 


100% 


225 




6/24/02 


6/25/02 


100% 


28,224 




6/26/02 


6/27/02 


100% 


227 




8/13/02 


8/14/02 


100% 


228 
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Develop and test PROD backup and 



restore procedures 


2 days 


8/15/02 


8/16/02 


100% 


229 




install DB on Dell web server and iAS on 














Dell DB server 


1 day 


8/12/02 


8/12/02 


100% 






Ship 1st LOPA server to LOPA 


2 days 


8/16/02 


8/19/02 


100% 


231 




Ship 2nd server to LOPA 


1 day 


8/20/02 


8/20/02 


100% 


232 




Examine single OTIS and Crystal 














Enterprise signon requirements 


2 days 


5/6/02 


5/7/02 


100% 






DMG: Revise views, reports, procs as 














needed 


10 days 


2/20/02 


3/5/02 


100% 






Integrate CR Enterprise and CR rpts 


2 days 


8/20/02 


8/21/02 


100% 


244 




Research and Monitor FDA Rule 1 1 and 














other federal regulations affecting LOPA 


5 days 


6/3/02 


6/7/02 


100% 




Mo 


Convert existing LOPA OTIS and web 










285FS+3 




server to DEV and TEST configuration 


3 days 


y/o/uz 


y/iu/uz 


i A AO/ 
1 UU/O 


days 


LUrA 


Conduct system test 


41 days 


o /o vl /no 

0/24/02 


8/19/02 


4 AAO/ 

100% 






define test scenarios for IT, UAT 


26 days 


GI*\A /AO 

6/24/02 


7/29/02 


H AAO/ 
100% 




1 no a 
LUrA 


Establish system test DB 


2 days 


6/28/02 


7/1/02 


100% 


OO-T OOO 

227,228 




Develop system test plan (validation plan), 














schedule 


6 days 


^ /on /no 

7/30/02 


0 /n /no 

8/6/02 


«t nno/ 

100% 


0 ii n 

240 




Prepare system test cases, scripts, data 


5 days 


8/7/02 


8/13/02 


100% 


242 




Conduct system test 


4 days 


8/14/02 


8/19/02 


100% 


241,242,243 




Conduct integration test 


79 days 


5/6/02 


8/22/02 


100% 






Develop integration test plan, schedule, 














scenarios 


3 days 


"7 /o /no 

7/2/02 


7 / >i /n 0 

7/4/02 


4 nno/ 

100% 


241 




Establish integration test DB 


1 day 


c/oc/no 

b/zo/02 


c/oe/no 


4 AAO/ 

IOOyo 


227 




LOPA: request current donor tape from 














OMV 


1 day 


c /c /no 
O/O/U^ 


c/c/ao 


<f AAO/ 

lOUvo 






Obtain current OMV tape 


1 day 


o/zu/uz 


C/OA/AO 


1 nno/ 
1 UUYo 


248 




Install/migrate CR reports 


1 day 


o /h /no 

8/1/02 


O/H /AO 
8/1/02 


H AAO/ 

1 00% 


215 




Conduct integration test 


3 days 


8/20/02 


8/22/02 


100% 


246,247,249,250,244 


Complete new app training 


30 days 


7/1/02 


8/9/02 


100% 






Define training approach, locations, 














participants, schedule 


1 day 


7/1/02 


7/1/02 


100% 




LOPA 


Identify training recipients and schedule 


1 day 


7/2/02 


7/2/02 


100% 


253 




Prepare AL (Acadian) training materials 


4 days 


8/2/02 


8/7/02 


100% 


254.276 




Prepare OTIS (LOPA) coordinator/tech 














training materials 


o days 


7 /O /AO 
7/O/02 


7 /A /AO 

7/y/U2 


*t AAO/ 

100% 


254 




rrepare \j i 10 ^ujrHj managemenx 














fro in inn m otorio !o 
Udllllliy 1 1 lalcl Idlo 


^ Hav/c 
O Udyo 




7/s/n? 

r / \Ji\JdZ. 


1 uu /o 


254 




Conduct Acadian training 


2 days 


Q /Q /no 
0/0/U^ 


O/A/AO 

o/y/uz 


1 nno/ 
n uuvo 


255 




Conduct LOPA coordinator, tech training 


3 days 


7/4 A /AO 
7/10/02 


7M O/AO 


H AAO/ 

1U0% 


256 




Conduct LOPA management training 


2 days 


7 /O /AO 
7/8/02 


7 /A /AO 


H AAO/ 

IUUto 


257 




Conduct user acceptance test 


46 days 


c /o^ /no 

6/27/02 


O /OA /AO 

8/29/02 


h nno/ 

100% 






Establish UAT DB 


1 day 


6/27/02 


n /o~T /no 

6/27/02 


1 00% 


247 




Obtain UAT test scenarios, test data 


0 days 


-7 /on /no 

7/29/02 


"7 /OA /AO 

7/29/02 


4 nno/ 

1 00% 


240 




Oofino 1 1 AT* o n n rn sa r» h crhoHi ilo 
LJtJUIItr Un 1 apjJIUaOM, oUllcUUIC, 














participants, locations 


2 days 


7/30/02 


7/31/02 


100% 


263 




Prepare test plan 


3 days 


8/1/02 


8/5/02 


100% 


264 




Prepare test scenarios, scripts, data 


5 days 


8/6/02 


8/12/02 


100% 


265 


LOPA 


Conduct UAT 


5 days 


8/23/02 


8/29/02 


100% 


262.264,265,266,251 


Prepare documentation 


91 days 


5/6/02 


9/9/02 


100% 






Refine user doc style, format 


2 days 


5/6/02 


5/7/02 


100% 
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Define user doc TOC 


1 day 


6/12/02 


6/12/02 


100% 


269 




Develop on-line app help display 


19.9 












procedure 


days 


7/1/02 


7/26/02 


100% 


270 


Lance 


Develop consolidated help print 














procedure 


1 day 


7/29/02 


7/29/02 


100% 


271 


Lance 


Develop text for Online help for each 














window 


30 days 


7/30/02 


9/9/02 


100% 


272 


LOPA 


Develop security plan (HIPAA/FDA Rule 














11 requirements) 


20 days 


6/19/02 


7/16/02 


100% 




LOPA 


Review security plan 


2 days 


7/17/02 


7/18/02 


100% 


274 


JMCS 


Create peformance test plan/benchmarks 














(measures) 


10 days 


7/19/02 


8/1/02 


100% 


275 


LOPA/JMCS 


Define technical doc TOC (System 














Documentation, Audit Footprint, Controls, 














Server environment setup documentation) 


2 days 


8/1/02 


8/2/02 


100% 




LOPA/JMCS 


Prepare technical doc 


1 5 days 


8/8/02 


8/28/02 


100% 


277 


JMCS 


Review technical doc 


1 day 


8/29/02 


8/29/02 


100% 


278 


LOPA 


Document DEV. TEST and PROD DB and 














iAS settings 


2 days 


o /on /no 
o/oU/02 


n/o /no 

y/^/uz 


a HAO/ 
100 70 


OCT 




Implement in production 


27 days 


Q 14 /ao 

O/1/02 


y/o/Oz 


a nno/ 
lOUvo 






Install and deploy production servers 


2 days 


O /O A /AO 

8/21/02 


8/22/02 


a r\r\Ci/ 

100% 






Define transition plan 


2 days 


8/1/02 


8/2/02 


100% 






Run and verify conversion procedures 


2 days 


8/23/02 


8/26/02 


100% 


283,251 




Switch to new application 


0 days 


9/3/02 


9/3/02 


100% 


284 




Conduct performance test 


2 days 


9/3/02 


9/4/02 


100% 


285 


LOPA/JMCS 


Test backup servers 


2 days 


9/5/02 


9/6/02 


100% 


286 


LOPA 


Provide 60-day post-implementation 














suppport 


60 days 


9/3/02 


11/25/02 


100% 


285 


JMCS 
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